Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

When Should an Analyst Suggest Using Queues in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:43:00 GMT

One of the most underrated skills for a business or system analyst in integration projects is knowing when to recommend a message queue — tools like RabbitMQ, Kafka, or Azure Service Bus.

Let’s be honest: not every integration needs one. But when it does, queues can save your system from chaos.

What Queues Actually Solve

Message queues are not just “another tech buzzword.”
They handle asynchronous communication — meaning systems don’t have to wait for each other to respond.

Example:
Instead of sending an invoice from System A and waiting for System B to confirm,
System A drops the invoice into a queue.
System B picks it up when it’s ready.

Benefits:

Smooth data flow even if one system is slow or offline
Built-in retry and error handling
Better scalability — handle thousands of messages per second
Natural decoupling between systems (less spaghetti logic)

When Analysts Should Recommend Queues
You don’t need a queue for every integration. But consider it when you see these signs:

High volume of transactions — more than a few thousand per hour.
Unstable or external systems — APIs that sometimes fail or have latency issues.
Different processing speeds — one system sends faster than another can receive.
Business-critical data — where you can’t risk data loss or duplication.
Complex workflows — where multiple consumers (systems) need the same event.

When Not to Use Queues

For real-time user interactions (e.g., “show me the balance now”) — queues add delay.
For simple 1:1 synchronous API calls — direct REST is cleaner and faster.
When the team can’t support monitoring (queues need visibility and alerts).

As an analyst, you don’t have to design Kafka topics or RabbitMQ exchanges.
But you should recognize the moment when a queue turns from “technical detail” into a business enabler — ensuring reliability, scalability, and peace of mind for everyone involved.

For Business/System Analysts who work with ERP integrations.

Andrii Siryi — Tue, 28 Oct 2025 15:42:00 GMT

When designing ERP integrations (for AR/AP document flows), Business/System Analysts often face a range of “gotcha” questions — technical, architectural, and sometimes unexpected.
Here are some of the real-world questions I ask clients during the API and ERP connector discovery phase:

What’s the minimum required ERP version to support all AR/AP endpoints?
Could upgrading the ERP version change the API behavior (fields, formats)?
Are there any heavy or slow API methods under load? Recommended workarounds?
Does the ERP provider charge for API calls, or is usage unlimited?
Can we get a list of possible API error codes?
Any record count limits per request? (e.g., max 1000 records in GET)
What type of authentication is used — Basic Auth, OAuth2, or token-based?
What’s the average response time of the API?
Are there any debug/logging tools if something goes wrong with the call?
Any breaking changes in recent patches that could affect us?
Does the API support batch insert/update or only record-by-record?
In what format are dates returned? Full datetime or date-only?
How are balances returned (positive/negative for credit memos)?
Can documents be posted without updating the "last modified" date?
Can an account include multiple subsidiaries? How to filter by them in the API?
Are any API methods planned for deprecation? What will replace them?
Are some API endpoints available only with paid ERP modules or add-ons?
Are some fields or features hidden unless specific ERP configuration settings are enabled?
Does the ERP API return full relational data (e.g., linked documents, GL splits), or do we need extra queries?
How can we detect deleted records if the API doesn’t expose a deleted flag or status?

These questions aren't just technical — they help avoid costly mistakes, failed syncs, or misunderstood logic.

Field Mapping vs. Canonical Data Model — Which One Wins in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:39:00 GMT

When building integrations between systems, one of the first architectural choices you’ll face is how to align data between them.
Two main approaches dominate this conversation: direct field mapping and the canonical data model.
Let’s break them down.

Field Mapping: Simple but Fragile

Field mapping means you connect each field from System A directly to a matching field in System B.
It’s fast to implement and easy to visualize:

Example:
“CustomerName” → “ClientFullName”
“InvoiceDate” → “BillingDate”

Pros:

Quick setup for simple integrations
Easier to debug and understand
Great for 1-to-1 integrations

Cons:

Every new system adds complexity — you end up maintaining dozens of mappings
Any field name or format change breaks the flow
Hard to scale beyond a few connections

This approach is fine for small, stable environments — like syncing data between CRM and ERP once a day.

Canonical Data Model: Structured and Scalable

A canonical model introduces a shared, unified data layer — a kind of “translation dictionary” for your enterprise.
Instead of connecting systems directly, each system maps to the canonical schema.

Example:
System A → Canonical Model → System B
“CustomerName” → “Customer.FullName” → “ClientFullName”

Pros:

Greatly simplifies multi-system integrations
Reduces maintenance costs over time
Makes it easier to add or replace systems

Cons:

Requires more design work upfront
May be overkill for small projects
Needs governance and version control

This approach shines in large ecosystems — where data flows across multiple ERPs, CRMs, or custom apps.

So… Which One to Choose?

If you’re connecting two systems and don’t expect frequent schema changes — use field mapping.
But if your integration landscape is growing and you want to reduce long-term pain — invest in a canonical model early.

Think of field mapping as a shortcut, and the canonical model as a foundation.

YAML-Based Story Mapping

Andrii Siryi — Tue, 28 Oct 2025 15:37:00 GMT

System Analysts who work with integration processes should formulate user stories in a way that diverges from the traditional structure. This is primarily due to the need for a more technical and structured description, which allows for the inclusion of integration-specific details.

The user story might need to specify exactly what kind of data should be retrieved via an API, from which system, using what HTTP method, and so on.
Additionally, such user stories can incorporate validation requirements.
For instance, before sending the data to an external system through an API, certain transformations or formatting might be required.

As a result, the structure of a user story in this context tends to differ significantly.

Here’s an example of how a story might look:

story_map:
epic: "Invoice Integration"

user_stories:

id: US001
title: "Obtain AR invoice"
as_a: "Application X"
i_want: "obtain AR invoices from ERP {{X}} via API"
so_that: "I can handle this invoice and send to the client"
source_system: "ERP {{X}}"
target_system: "Application X"
direction: "pull"
api_call:
method: "GET"
endpoint: "/api/invoices"
auth_required: true
id: US002
title: "Validate data"
as_a: "Application X"
i_want: "validate the fields of the received invoice"
so_that: "I don't sync the invoice with errors"
validation:
invoice_number: "required"
invoice_id: "required"
invoice_total_amount: "should be > 0"
invoice_status: "should be 'posted'"
id: US003
title: "Push invoice payment"
as_a: "Application X"
i_want: "push the invoice payment created in Application X to the ERP"
so_that: "the payment is approved in the ERP and synchronized back"
source_system: "Application X"
target_system: "ERP {{X}}"
direction: "push"
api_call:
method: "POST"
endpoint: "/api/payments"
auth_required: true

Change Management Process in Software Company or How to Overcome Your Change Request Fear

Katia Vizhan — Mon, 09 Jan 2023 11:04:00 GMT

Context:

Intro
Change Request Definition
Reasons for CRs
Adaptive, predictive and mixed projects
Flow of processing change requests
Change Management Workflow
Tools and Techniques

1. Intro

The World will never stop changing, as well as human needs and desires. The business environment evolves continually. An organization that fails to take over rising needs becomes obsolete and loses out in the long run. Take the mobile phone brand Blackberry, for instance. The one-time smartphone favorite, which had over 80 million users worldwide, recorded a 0.2% market share in 2016 due to its failure to adopt touchscreen technology. Change is a necessity for businesses to survive. That is why we often have to deal with change requests while working on project development. This article aims to demonstrate that there is nothing bad and negative about working with change requests if you know what to expect and are acquainted with tools to help you.

2. Change Request Definition

To start with,we need to define what a change request is so that we are all on the same page. Change requests(further - CR) are appeals to make a change to a requirement or other suggestions for changes to product information that are raised by the business stakeholders or project team after a set of requirements is baselined. (The PMI Guide to Business Analysis)

Types of CRs

System logic/behavior changes
Scope changes
Changes in naming/wording
Changes in UI
Technical changes (integrations, languages, etc.)

Removing items from the scope is also an example of changes to the scope of work. Items can be removed from an iteration’s scope for various reasons, including the following:

Implementation issues are preventing an item from being completed within the current time frame.
Issues discovered by product owners or during testing make the implementation of a particular user story unacceptable.
Higher-priority items need to replace less important ones that have been planned for an iteration.

It is like when you are planning to build a new house and after estimates have been given, the budget and project have been confirmed, the building process has started and you decide to change something. This might seem to be an example that is far away from software, but it will help us a lot throughout the article to illustrate the theory and make it more practical.

3. Reasons for CRs

Stakeholder changes their mind (1)
Recommendations after seeing part or all of the solution (2)
Risks (3)
Regulatory change (4)
Poorly defined/missed requirements (5)
Internal or external constraints (6)
Change in Sponsorship (7)
Business Strategy Change (8)
Updated Technology (9)
Insufficient Resources (10)
Natural Disaster (11)

So, going back to our house. Instead of the monolith that was an initial solution in the project, we have used ready panels. The monolith is a good thing, but when the ground is good and the building is pretty small there is no necessity to use a monolith which is more expensive, harder, and longer to assemble. We defined this requirement poorly as we did not have enough competence at the outset(5).

Next, according to the house project, we were supposed to use special panels to make an incline of the roof, but these panels are not produced anymore, so we could not buy them, so we decided to make it from light concrete. Here we had to deal with external constraints(9). It can be compared to a software technology that changes when it is already in use in the project.

In addition, we ended up buying windows made from a German profile. The windows that we planned to buy initially were produced in Belarus. And this country, instead of sending its goods to Ukraine on export, is now sending Iskander ballistic missiles to Ukraine for no rhyme or reason.So, this is (4) - a regulatory change as Ukraine does not purchase products from Belarus anymore.

Moreover, the Knauf plant, a producer of building materials, construction systems, etc. had been destroyed by the russian army which keeps bombing civil infrastructure, so now we need to search for another plaster producer (11 + 6). This is an obvious example of how force majeur is combined with external risks.

4. Adaptive, predictive, and mixed projects

While working with change requests we should consider the following criteria:

Project type
Budget
Communication
Client’s policy
Project phase
Architecture

How one handles change requests depends on many project characteristics, including the type of contract (fixed price or time and material), project management approach, etc. If you have a limited budget for house building, that is a fixed price. Under such circumstances, workers can offer you a certain house to be built in a certain period. That is when workers need to know all the requirements in advance to provide you with an estimate.

It might seem that it is almost impossible to introduce change when you work on a fixed-price project. Such kinds of projects are like sour lemons - no one wants to work with changes on them as if they occur, a lot of steps of the change management process should be made, to make the project go smoothly. However, we need to consider the “policy” of the service provider - whether the client is important to the company outside of the context where the company aims to earn money and what the budget of the project is. Fixed price projects by default means significant risks, assumptions, and constraints, hence a safety cushion is made to factor in all above mentioned. So, sometimes the team can agree to a CR implementation for the client “for free”. But it is very important to communicate the whole process, so stakeholders will understand the value and won't abuse the situation. And the lemon appears to be not that sour when you know you can eat it with sugar - so, you need to be armed with a corresponding instrument to rule.

Also, it is very important to consider the stage of the project when the change appears. If you already have built the walls of your house, it is better not to change the plan of the house. If you decide to move an already-built wall, you will need to ruin what has already been done. So, the later the stage, the more expensive the change.

In adaptive approaches, there is no formal change request process. When a stakeholder requests a change, it is written in the form of a user story and added to the backlog. These are typically not referred to as change requests. A prioritization process is used to evaluate product backlog items against existing backlog items to determine which items will be included in the next iteration. The prioritization process works to ensure that the team focuses development efforts on the stories deemed of the highest importance and value.

In the real software world, we usually work on mixed projects… We stick to the Times and Materials contract type but usually have some limitations.

Usually, software companies prefer to deliver work in sprints, so there is some advice that you have to consider while working with CRs in sprints:

Don’t take CR into an ongoing sprint
Don’t perform unscheduled groomings
Do inform the client that the team’s velocity will drop
Do take out tasks from the ongoing sprint to fit in the change request
Do stop the ongoing sprint and start a new one
Do switch from Scrum to Kanban if changes occur often

5. Flow of processing change requests

So, now that we know what CRs are and when they can occur, we need to figure out how to manage them. The change management process is a series of tasks outlined for a seamless transition from a current state of affairs to a new one without obstructing the workflow or suffering any damage. To build such a process the team has to define how each step of the process will be conducted.

● Determine the process for requesting changes (specify which requirements and designs the change control process covers and determine whether it applies to all changes or only to changes of a specific size, cost, or level of effort. This process details the steps for proposing a change, when changes can be proposed, and who can propose them).

● Determine the elements of the change request (identify the information to be included in a proposal to support decision-making and implementation if it is approved. Possible components to consider on a change request are:

Cost and time estimates: for each area affected by the proposed change, the expected cost of change is estimated.
Benefits: an explanation of how the change aligns with the initiative and business objectives to show how the change adds value. The benefits considered include both financial benefits and tactical benefits such as implications to scope, time, cost, quality, and resources.
Risks: an analysis of risks to the initiative, the solution, or business objectives.
Priority: the level of importance of the change relative to other factors such as organizational objectives, regulatory compliance requirements, and stakeholder needs.
Course(s) of action: the course of action for the change includes an assessment of the components of the change request (cost, time, benefits, risks, and priority). It is common to identify several alternative courses, including those recommended by the requester and by other stakeholders so decision-makers can make a choice that will best serve the needs of the initiative.

● Determine how changes will be prioritized (the priority of the proposed change is established relative to other competing interests within the current initiative).

● Determine how changes will be documented (configuration management and traceability standards establish product baselines and version control practices that identify which baseline is affected by the change).

● Determine how changes will be communicated (how proposed changes, changes under review, and approved, declined, or deferred changes will be communicated to stakeholders).

● Determine who will perform the impact analysis (specify who is responsible for performing an analysis of the impacts the proposed change will have across the initiative.

● Determine who will authorize changes (include a designation of who can approve changes)

6. Change Management Workflow:

All the above-mentioned information helped us to create our custom Change Management Process adapted to our needs.

6.1 Identify CR

When a request is received we need to identify that it is something new the client is asking for, not something that does not work properly.

A bug is something that is broken in a requirement that has already been implemented.

A change request needs to go through a cycle in which the impact and effort have to be estimated for that change, and then it has to be approved for implementation before work on it can begin.

I'd say that if the color of the home page was originally designed to be red, and for some reason it is blue, that's easily a quick fix and doesn't need to involve many people or man-hours to do the change. However, if the color of the home page was designed to be red, and is red, but someone thinks it needs to be blue, that is, to me anyway, a different type of change. For instance, has someone thought about the impact this might have on other parts of the page, like images and logos overlaying the blue background? The link underlining is blue, will that stand out?

Bug VS CR:

Clients won't be paying any extra money for bugs under fixed-price contracts. The client places a request, the provider estimates it and puts a number to it, a contract is signed and a price is agreed upon. That price is as much as the client is going to pay. Any defects will come under the contract, which means the client won't be paying any extra money for it, while change requests will be part of a new contract, which means the client will pay extra for it. Here is a good argument for debate.
Service providers may be penalized if more than a certain number of bugs appear under the Service Level Agreement (SLA). SLA may state that the provider may be penalized if more than a certain amount of bugs appear, which is another reason to fight for the change-request category.
Regardless of whether the customer pays for it or not, a defect always raises doubt about satisfaction; if the client gets the impression the work isn't done properly they may end up choosing a different provider hence leading to you losing a revenue channel.
Unhappy developers
Poor statistics in bug reports

6.2. High Level Elicitation

When we have identified a change request we need to define the scope of the requirement necessary for high-level estimation.

The following steps from 6.3. to 6.8 describe Impact Analysis that has to be conducted while working with CR. Below is what you need to take into consideration doing Impact Analysis:

Requirements Baseline
Conflict: whether the proposed change Conflicts with other requirements
Benefit: what will be gained by accepting the change
Cost: the total cost to implement the change including the cost to make the change, the cost of associated rework, and the opportunity costs (number of other features that may need to be sacrificed or deferred if the change is approved)
Impact: the number of customers or business processes affected if the change is accepted.
Schedule: the impact on the existing delivery commitments if the change is approved.
Urgency: the level of importance including the factors which drive necessity such as regulator or safety issues.

6.3. Analyze the Impact

Here we need to identify related requirements (user stories, epics, modules) that help to clarify the scope of work.

6.4. Schedule Estimation Session

When a Business Analyst is ready with his part of the work, then the Project Manager can schedule an estimation session to understand the cost of the change.

6.5. Estimate

The estimation session itself is conducted in line with the rules that exist on the project. Usually, it is a rough estimation as we have gathered enough details to understand the size of the CR.

6.6. Present Estimation Results

When an estimate is received, the Project Manager has to communicate it to the client. We know that money is usually a key aspect of requirements approval and prioritization.

6.7. Approve

It is necessary to receive approval from the client:

Rejected CRs are to be Obsolete or moved to any other status identified within the project (eg.: Rejected, ect.).
Approved, but postponed CRs have to be prioritized into an appropriate release or put into the backlog.
Approved for the current release are to be processed.

6.8. Update Timelines/Present to client

The Project Manager is then responsible for updating the project artifacts showing timelines. Adding changes usually requires additional time, so the timeline of the project changes moving forward. If a change request removes features from the scope, then timelines might change so that the release date will occur earlier. This also has to be communicated to stakeholders as it might happen that an earlier delivery date is not possible due to some agreement with the previous service provider.

6.9. Confirm Timelines/Offer Tradeoffs

If the client is not satisfied with the new timelines, then the team can offer tradeoffs. We can either think of a different way to implement the change to trim the estimate, or we can remove some items from the planned release to fit the CR and stick to the timelines.

6.10. Document Requirements Changes

Here we should find a method to show the changes in the requirements: logic, behavior, and approach to implementation. Sometimes the client request might change the behavior of the system that is already implemented, but due to a number of reasons it is postponed till the next release, so it does not impact the scope of the current iteration. So, it is an enhancement to the existing requirement, but not a CR.

6.11. Document Scope/Effort Changes

Here we need a way to document that the CR was approved and now should be taken in an already planned release/iteration. This is how we show that the baseline has changed and how we can define later why the timelines were changing.

6.12. Update Change Log

If it is agreed on the project that Change Log has to be managed then it is part of the Change Management Flow. My Business Analyst team and I insist it is the responsibility of the Project Manager

6.13. Process Requirements

No matter whether a requirement is determined as CR or not, it has to go through the same process to be shared with the development team and delivered to the client.

7. Tools and Techniques

And here comes the most interesting part: how we document all of the received information. I offer the following approaches to documenting:

Requirements Changes:

Versions of requirement/ additional issue type (CR)/ [CR] in requirement title
1. Versions of requirement
2. Additional issue type (CR)
3. [CR] in requirement title
"Archived" status/"Actual Version" label
1. "Archived" status
2. "Actual Version" label
Related issues

1.i. Versions of requirement

1.ii. Additional issue type (CR)

2.i. “Archived” status

2.ii. "Actual Version" label

3.i. Related Issues

Scope/ Effort Changes:

Additional issue type (CR)/ [CR] in requirement title
Label [CR]

1. Additional issue type (CR)/ [CR] in requirement title

2. Label [CR]

Select different techniques for different purposes! To make it easier for users and contributors to see precisely what notable changes have been made between each release (or version) of the project.

4 essential software skills for HR business analysts

Gnanasekar — Tue, 05 Jul 2022 06:31:00 GMT

Are you in the process of hiring an HR business analyst? There is a growing demand for candidates for this role, and there are so many factors that can influence the quality of your hire – one of which is the software skills they have. Because they rely on software to analyze and enhance the quality of their hires, an HR business analyst will need top software skills.

If you end up hiring an HR business analyst who lacks the software skills required for the position – or the wrong software skills for your organization – you might run into a few problems. You’ll find that training sessions will be required to get your HR business analyst up to speed, which costs your organization extra time and more money.

So, to help you avoid this, this blog covers:

What HR business analysts do and why data is important in the role
Why software skills for HR business analysts are important
Which software skills should you be looking for in HR business analyst candidates
How you can evaluate the required software skills for business analysts
The advantages of skills testing for analyzing HR business analyst’s software skills

What do HR business analysts do and why is data important for this role?

HR business analysts are responsible for analyzing your organization’s HR department data. They gather the data, analyze the information, and finally use the information to manage and streamline how your department attracts candidates while keeping costs low. This is the reason why data is essential for the HR business analyst’s role.

Their position also includes enhancing the quality of the candidates your department attracts and handling issues with staffing in your organization. But their role goes a step further too, as HR business analysts use their comprehensive understanding of staffing and recruitment laws in their role to comply with them when making recruitment department decisions.

HR business analysts also make sure employee productivity is efficient. They achieve this by communicating with employees to discover gaps in their skills. If they find that any skills are missing, it is the HR business analysts’ role to create and provide a report to senior management.

To this end, software skills for HR business analysts are crucial. Not only do they help track employee and company data, but the software skills are used to create reports and feedback to management. They can even help automate tasks.

Why else are software skills for HR business analysts important?

There are various other reasons why software skills are important for HR business analysts. The software that HR business analysts use helps to streamline their work and maintain the quality of their HR data.

Analyzing employee data requires an understanding of software and systems as well. For example, one type of system HR business analysts should be familiar with is HRIS, or Human Resources Information Systems, which are fundamental to data analysis within the context of your company.

Which software skills should you be looking for in HR business analyst candidates?

We’ve mentioned that HRIS systems or software are critical for the HR business analyst role you’re hiring for. But there is also a selection of essential types of software that your HR business analyst candidates should be familiar with as well. Take a look at the following types of software. Do your candidates have skills with these?

Microsoft Excel

Your HR business analyst will need to use Microsoft Excel throughout the process of gathering and analyzing employee data. For this reason, they need to be competent and confident in using Microsoft Excel and its advanced features.

Not only will they need to analyze the data they store in the Microsoft Excel software, but they will also need to keep employee data organized and draw conclusions and insights from the data they collect.

Your HR business analyst candidates should also be familiar with the reports feature provided on Microsoft Excel to create reports for stakeholders. Taken together, these skills are fundamental to the success of an HR business analyst candidate.

Power BI

Another software skill you should be looking for in your HR business analysts is their knowledge of Power BI. The software can streamline and make it simpler to distribute data analytics that corresponds to the employee data they have collected.

Software skills in Power BI are vital to the success of your HR business analyst candidates for various reasons. As your candidates will be using the software to prepare data well as interpret tables and statistics, they will need to be familiar with Microsoft Power BI.

Tableau

As managing data is at the heart of your HR business analyst’s role, they will need to be confident when using Tableau software. As with Microsoft Excel and Power BI, software skills in Tableau can make a significant difference to how successful your HR business analysts will be in the role.

Skills in Tableau are important. This software is the key to making data-driven hiring and recruitment decisions – which your HR business analyst will be carrying out every day.

Data visualization is also crucial to the HR business analyst role, which is exactly why your candidates should be able to use Tableau confidently. If your HR business analyst can build visualizations for the data they collect via Tableau, they will then make it easier for their recruitment team to understand the data with ease.

Microsoft Windows

Knowledge of Microsoft Windows is highly recommended for HR business analysts. The reports and files created in Microsoft Windows all need to be handled, saved, and accessed via the Microsoft Windows software platform, so your candidates should be familiar with this.

As well as being able to use Windows File Explorer, your candidates should understand the basic functions with ease to store and organize employee data files.

How you can evaluate the required software skills for HR business analysts?

When it comes to evaluating the required skills for your HR business analysts, there’s one key, simple way to do it – use a reliable skill-testing platform to your advantage. The top skill-testing platforms will feature a huge selection of tests, ranging from Microsoft Windows to Microsoft Excel. These tests are beneficial for various reasons, which we will get into later.

Below, we have included the essential skills tests that will make assessing your HR business analyst candidates’ software skills a breeze.

Microsoft Excel (advanced) software skills test

Find out how confident your candidates can use Microsoft Excel at an advanced level by giving them a Microsoft Excel (advanced) software skills test. Use the results to dig deeper into your candidate’s knowledge of producing reports from the data they have gathered and how well they can gain insights from data.

Power BI software skills test

Use the Power BI software skills test to discover how technically skilled your candidates are with this software. Find out if they are competent with data visualization, whether they can distribute data across your organization, and have data preparation aptitudes that will help them be successful within the role.

Tableau software skills test

To get more information on how well your candidates can use Tableau software, you’ll need the Tableau software skills test. This test will help you evaluate how confidently your candidates can manage data, create and perform advanced calculations, build visualizations, and organize data. It’s also ideal for understanding whether your candidates can gain insights from the data they store in the software to make recruitment decisions.

Microsoft Windows software skills test

If you want to accurately assess your candidate’s Microsoft Window software skills, the Microsoft Windows software skills test is what you’ll need. It will help you find out how confidently they can store, access, and move data and files in Windows File Explorer, and whether they can understand the basics of Microsoft Windows.

Key benefits of skills testing for assessing HR business analyst’s software skills

There are three main advantages of using skills tests to assess your HR business analysts’ software skills. The main benefits are:

Testing a vast selection of software skills used in the HR analyst position is easy. All you need to do is select from the extensive range of skills tests on a reliable skill-testing platform and distribute the software skills tests among your candidates.
Reducing your cost-per-hire is no problem. Recruitment costs can add up the longer it takes to make a hiring decision. With a software skills test, you’ll find it simple to instantly filter the HR business analyst candidates who are unqualified for the position. This reduces time-to-hire and, in turn, your company’s cost-per-hire.
Choosing candidates who will perform well in the role is simple as the results will indicate which candidates are software superstars. No longer will you have to rely on personal opinions or ‘gut feelings’ about candidates. Choose the most competent candidates who have the best software skills for the position.

Hire top HR business analysts with the best software skills for the job

It’s vital to learn as much as you can about your candidates and their software skills in the time that you have. But although it might seem challenging, this doesn’t need to be difficult! Software skills tests on reliable skills testing platforms will:

Give you more information on your candidates’ software knowledge
Help you avoid hiring bias, and
Keep your time-to-hire low

They will make your hiring decisions easier.

Top 10 Mistakes in Requirements Elicitation

Trividh Patel, CBAP — Tue, 27 Apr 2021 05:47:00 GMT

Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified.

1. Not understanding underlying business need

Organization’s business environment keeps changing with respect to Customers, Marketplace, Technology and Marketing function. It is these changes in business environment that leads to identification of business needs at the strategic level in terms of problem or opportunity faced by the organization.

Defining business needs is the most important step in business analysis. Without understanding and defining underlying business needs, it would not be possible to identify all affected stakeholders and elicit appropriate requirements.

2. Not identifying all affected stakeholders

It is important to identify all the stakeholders affected by the given business need. If any stakeholder is identified late (or worst not at all!) may lead to incomplete set of requirements and could require a revision to requirements increasing project cost and time.

3. Treating elicitation as a phase

I have found many Business Analysts consider elicitation as a phase after planning (and before requirements analysis). But this is not true. If you think little more deeply, information gets elicited whenever we interact with stakeholders such as sponsor, domain subject matter experts (SMEs), implementation SMEs, users etc.

Elicitation is performed to understand the current state and elicit business requirements. Business requirements are used when eliciting stakeholder, solution and transition requirements. During requirements analysis, we may identify gaps which would require further elicitation. Information is also elicited from the stakeholders about solution performance after implementation of a new solution.

So elicitation is performed on an ongoing basis as long as business analysis work is performed.

4. Not asking probing questions to elicit requirements

Many novice Business Analysts assume stakeholders can proactively provide all the detailed information required for the business analysis work. Such a passive approach can be called requirement gathering but not an elicitation. Such an approach can only lead to identification of shallow requirements.

It is the job of the Business Analyst to extract or draw out the detailed requirements from the minds of the stakeholders. Business Analyst need to ask probing questions to elicit detailed requirements.

5. Not setting stakeholder’s expectations

In your career as a Business Analyst, at times you would find some stakeholder who would state their wants (whims and wishes!) as if they are their needs and expect them to be in the solution. You may find their expectations not only difficult but impossible. If you capture their wants as requirements it would be difficult later on to deliver to their expectations.

With your interpersonal and negotiation skills you need to communicate and set the right expectations.

6. Not using combination of complementary elicitation techniques

I have seen many Business Analysis teams often rely only on one technique such as interviews for elicitation. While interviews is the most effective elicitation technique but its effectiveness depends on the skills of the Business Analyst such as business domain knowledge and ability to ask probing questions.

So, apart from interviews, a Business Analyst should have knowledge of other commonly used fundamental requirements elicitation techniques such as Document Analysis, Observation and Prototyping. While a senior Business Analyst should have knowledge of advanced elicitation techniques such as Brainstorming, Focus Groups, Requirements Workshops and Surveys.

A Business Analyst should be able to understand the given situation and use combination of complementary elicitation techniques.

7. Not eliciting assumptions and constraints

Requirements are often stated (knowingly or unknowingly) based on certain assumptions which are believed to be true at that time. Requirements get impacted if those assumptions are later found to be false.

Constraints are limitations or restrictions (such as regulatory restrictions, budgetary restrictions, time restrictions etc) that restrict potential solutions to requirements. Identified potential solutions may change if there are any changes in the constraints.

If underlying assumptions and constraints are not captured for requirements, it would be difficult to assess impact on requirements if certain assumptions are later found to be false and/ or on potential solutions if constraints are changed.

8. No plan to elicit requirement iteratively

In order to elicit requirements, a Business Analyst contacts a stakeholder and requests their time. Many Business Analysts do not plan to elicit requirements iteratively and assume that stakeholders will provide all the information required for the business analysis work.

However, most of times, stakeholders are not aware why they are being contacted. After their initial meetings, stakeholder will have some idea what is expected out of him/ her. In the subsequent meetings, stakeholder is likely to give bit more detailed information. So, in order to elicit detailed information, Business Analyst needs to plan to elicit requirement iteratively.

9. Not confirming the elicited information

Work of elicitation is not over once Business Analyst is done talking to stakeholders. Business Analyst has to organize the elicited information and send it to the stakeholders for review. The purpose is to check if discussion has been properly documented and confirm the elicited information.

10. Not collaborating with stakeholders to have common understanding of requirements

When the elicited requirements are shared with stakeholders, there can be difference of opinions and conflicts between stakeholders. A Business Analyst has to collaborate, mediate and resolve conflict between stakeholders to reach a common understanding of requirements. Business Analyst should identify the stakeholder’s problems and help to identify solutions to satisfy those problems.

About Author - Trividh Patel, CBAP

Trividh Patel has about 20 years of experience in Business Analysis and Consulting in IT services industry.

Currently, he is working as Facilitator and Mentor - Business Analysis providing self-paced online courses in Business Analysis. Previously, he has worked for leading IT Services companies as Business Architect, Lead/ Sr. Business Analyst, and as IT Project Manager. He has executed several business analysis projects for reputed organizations from USA, UK, Europe, Middle East, Japan and India. He has good track record of leading team of Business Analysts to deliver business analysis projects.

Trividh Patel has done MBA in Systems and Bachelor of Engineering from University of Mumbai (India) and is Certified Business Analysis Professional (CBAP) by International Institute of Business Analysis (IIBA), Canada since March 2012. He is also Certified Six Sigma Black Belt.

For Consulting, Coaching or Guidance on IIBA Certification (or just to connect!), Trividh Patel can be reached on LinkedIn: http://www.linkedin.com/in/trividhpatel-cbap

What is common between ‘agile’ methodologies and emotional intelligence (EQ)?

Ekaterina Barabash — Sat, 10 Nov 2018 14:30:00 GMT

I address my thoughts to those who are in IT management for whom the terms such as quality of project implementation development and profitability indicators of the company are important. And it is also addressed to business analysts whose daily routine is the process of communication with Customer.

A little about myself first.

The last 8 years I work as an IT business analyst and of course as any business analyst I’m like a ‘link’ between the world of Developers and world of Customers. It turns out, probably because of my personal qualities; I pay a great attention to the importance of building a healthy and trustful relationship with both team members and Customer.

After all, we are pleased to come to work and communicate with people who have a common goal with you and who understand you well.

Therefore, in addition to the necessary hard skills, I find soft skills very important.

Because of that I’ve come to studding the methods of development of emotional intelligence (the development of my emotional intelligence first!).

The more I was interested in the methods of evolution of emotional intelligence the more I was having the feeling that I had already heard about it and practiced it. I was just looking at it from a different side and different angle. Specifically, it is about practicing Agile methodologies. Of course, in reality each company, well, each team adapts the methodology to it’s realities, however one of the main principals of Agile methodologies is people!

People and interaction are more important than processes and tools.

For me personally it’s very important and valuable (hmm, I’m not sure whether this principle is as important for my IT colleagues as for me). Specifically, quality interaction with people and the development of these skills teach us methodologies for development of emotional intelligence as well.

In Agile for preliminary working with a new feature we use User Story, that consist of:

As a , I want so that .

I.e. .

For development of emotional intelligence and communication with other people we are taught to use the following formulation:

‘I feel…, because of…, and I would like…’

I.e. .

It turns out that by increasing our emotional intelligence we learn to think clearly and structurally, call things by their proper names, understand and pronounce the final goal.

Using Agile methodologies and emotional intelligence in work, we learn to create good cooperation and understanding with colleagues and Customers.

Did you notice the word of business is very unstable and started changing very fast comparing to the world we witnessed just about 15 years ago. And now the continuous changes in business are an unspoken norm.

Well, this is a problem of business, you’ll probably think…

But after all, we as Executors should satisfy the needs of business, help to make the Customer's business more profitable, because they pay us and their success is our success too.

This especially applies to Product Development and it's super important here!

What conclusion does one suggest? Executor takes responsibility to follow the changes brought up by Customer.

It’s like a tango dance where partners move synchronically.

Synchronization of business and IT cannot be done without quality emotional interaction. It is a very important factor allows us to respond quickly to changes, helps to understand needs and demands, gives the ability to be flexible, allows to anticipate changes in Customers business. If interaction is not established properly it takes longer time to understand and therefor we loose development time, it brings a delay in release, loss of reputation and sense of further development in general.

I think, that the new format of communication such as interaction, should be integrated as obligatory part of corporation communication and interaction with Customer.

What does it mean emotional interaction? Do we really understand when it appears and how to establish it?

Obviously it appears in everyday life when people talk about common stuff, without formalities, without any roles and ranks, just everyday topics.

What is needed to build human relation?

Eye contact. We should see the person. The scientists have proven that the human brain reads 80% of non-verbal information. The modern technologies provide us with a variety of possibilities.
Physical presence. When you are in the same room it’s much easier to communicate and exchange thoughts. It’s even easier to establish a better contact with a person who communication did not work out with initially due to certain reasons.
Introduction of regular mandatory coffee meetings, lunch, whatsoever, where people mostly talk about there life and interests rather than work. Here we are all just human beings, not a part of the IT world or business. We appear to have common interests and problems. Please note, I don’t mean a friendship, I talk about creating a good understanding between people. When it comes to work, the base of relationship created this way helps in discussing complex topics and solving problems.

	I’m sure this list of how to build human relations can be extended by experts in emotional intelligence and psychologists.

It’s very important for me what do you think? How do you create a productive relationship with Customers?

I would be grateful for any comments and reviews.

Identifying requirements, the right way

Surbhi Mahnot — Mon, 10 Apr 2017 06:10:00 GMT

Requirements define the needs of the project to provide best of its utility and benefits. If they aren’t clear or analysis is not done properly, it might lead to failure of the project no matter how good the concept and design is.

Just as a system is composed of various functionalities, requirements too are identified in various forms. This categorization of requirements makes analysis process much simpler and clear for all the involved stakeholders. As per BABOK, the requirements are primarily categorized as:

Business Requirements
Stakeholder Requirements
Solution Requirements - Functional and Non-Functional Requirements
Transition Requirements

With so many requirements to identify it is very easy to get confused with how to identify these requirements?

A simple approach is to visualize the complete process and start step by step

To do that, let’s look at cooking for an example:

When you plan to cook a meal, you first take in account for whom you are cooking. Is it for yourself or for your family or the kids? These define your Business Requirements. Once you decide this, you figured that you will sip wine along with the food and the kids won’t eat spicy food (stakeholder’s requirements). Next, you get all your ingredients for the meal (functional requirements) and you might also take in consideration the time you require to prepare the meal and preparation required for serving the food (Non-functional requirements). Finally, you prepare a delicious penne arrabbiata pasta topped with oregano and basil leaves (technical requirements).

Now, let’s understand each of these requirements with a technical example, Implement Log-in functionality.

Business Requirements: These are high-level business objectives or goals or needs of an organization. The business requirements document (BRD) usually includes what features would be there in the product, what market the business will expand or enter, risk assessment, success measures from the business point of view, etc.

Example: There shall be a Login screen through which Users will log into the system.

Tip to identify:

Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.

Stakeholder (User) Requirements: These are what every stakeholder needs/expects from the solution and how they will interact with the solution. Often the stakeholders can explain the entire system in detail from their perspective only. Each stakeholder sees the problem from unique perspective. Therefore, you must understand all the needs to understand the complete system. All these requirements must be analyzed in such a manner that it doesn’t conflict with each other.

Example:

As a customer, the user shall be redirected to Dashboard on successful login. (Stakeholder - Customer).

As an admin, the user shall be redirected to the Administrator’s landing page on successful login. (Stakeholder - Administrator).

Tip to identify:

Similar to business requirements, but from user's perspective. Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.

Solution Requirements: These specify the detailed conditions and the capabilities that the solution must have to meet the business and stakeholder requirements. Software Requirements Specification (SRS) is created to capture both functional and non-functional requirements. These are categorized into two:

a. Functional Requirements: These define specific behaviors, responses, information, rules for the solution primarily addressing the following:

The features the system will support (Functional capabilities)
Data validation rules and how they will be managed (Business Rules)
Interaction between different stakeholders (users) within the system (Use cases)

These include a complete description of ‘how’ the system will be built.

Example:

Registered users shall be able to login with valid username and password
On successful login, user shall be redirected to a landing page in the system
On failure, for not registered username prompt "Username not registered" message and for invalid credentials prompt "Invalid credentials"
New users shall be able to register with the system by clicking on the "Sign-Up" link
Users shall be able to recover password by clicking on "Forgot Password" link

b. Non-functional Requirements (Quality-of-service): These define the environment in which the solution will operate. The qualities a solution must have or constraints within which it must operate smoothly. They define standards for Usability, Reliability, Security, Accessibility, Performance, Information Architecture, Portability, Extensibility, Internationalization, Integrity or anything that would help the success of the system in real-world.

Example:

Performance: On successful login, user shall be redirected to the landing page within 10 seconds (max)
Maintainability: Proper logs stating the operation result with timestamp shall be added on every login/signup/forgot password click
Platform: The login functionality shall behave same on different platforms (Windows/Linux)

Tip to identify:

To easily identify between these, functional requirements can be considered as “verbs” and non-functional requirements as “adjectives” on these “verbs”.

Transition (Implementation) Requirements: These define conditions or capabilities only required to enable transition of the solution from development to real-word business use. It describes what must be done with the process, technology, education, training, enhancements before getting from the as-is into the to-be.

Example: Not valid in this example but for explanatory purpose: The login system shall behave same once "Single Sign-On" functionality is implemented

Tip to identify:

Look for temporary requirements such as “migrate from old system to new system”.

There are many other types of requirements that are used across diverse types of systems based on the scope such as:

Technical Requirements: Once the solution requirements are clear, the best way to start with the development frequently involves technology. It is a way to communicate between analyst and engineers (programmers, architects, designers) and is often written by the technical engineers. These requirements specify design and architecture for the solution components to be developed and implemented. They define how the solution will be programmed, store data and display data.

Example:

Browser support: Current and recent versions of Firefox, Edge, Chrome, Internet Explorer, Safari, Opera
Requires browser to have JavaScript enabled

Tip to identify:

Technical jargon's are used such as “password encryption algorithm” and “database schema” etc.

User Interface Requirements: These define the user interface design for the functionalities (derived from solution requirements). The placement of user input controls, buttons, links etc. on screen to allow the working of the functionality. Generally represented with wireframes.

Example:

Textboxes for username and password shall be placed below the respective labels for Username and Password
Login and Cancel buttons shall be present in center of the screen
Sign-Up link shall be present below the Login button
Forgot password link shall be present above the Login button

Requirement analysis is all about understanding, identifying and categorizing these requirements. With categorized requirements, it becomes much simpler for the team to understand and follow the system details.

#requirements

Defining Requirements

Surbhi Mahnot — Thu, 16 Mar 2017 12:47:00 GMT

All professionals talk about identifying business needs, identifying requirements to create tools so that they can help businesses take better decisions. In your career as an IT professional, I am sure at some point you must have heard terms such as “Requirements”, “Business Requirements”, “Software Requirements”, “Project Requirements”, “Technical Requirements” and the list goes on.

So, what are these requirements?

“Ours is a world where people don’t know what they want and are willing to go through hell to get it.” — Don Marquis

Well, to most of the people, this appears to be a simple question. But, this is the most complex question to answer (for the professional responsible to gather requirements, primarily a Business Analyst) as it takes forever to ask and understand “What are the requirements”.

Different people have different ideas of requirements. For a product owner, requirement is as simple as the ability to use/sell the product that helps with the business and revenues. For a project manager working on that solution, requirements are to get the solution developed with best quality that meets all the expectations of the client and minimize resource allocation to bring most benefits to the company. For a team lead, requirements are to identify the technical challenges, build a maintainable architecture and get the solution developed smoothly. For a developer, requirements are to develop the assigned feature or make changes in the software as requested.

Requirements, at first glance are really needs (end objective), wants, suggestions or ideas. Derived from those needs, we set an objective and take a decision about what things should be done or not to be done to achieve that objective.

Requirements are a set of prioritized needs from all the involved stakeholders that form the base for the functionalities or features to be included as a part of the solution.

Per BABOK guide, official definition of requirement is:

1. “A condition or capability needed by a stakeholder to solve a problem or achieve an objective.” In simpler words, a decision-making process to derive requirements from needs.

2. “A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents.”It is a step where business requirements are drafted as solutions requirements to get started with developing the solution.

3. “A documented representation of a condition or capability as in 1 or 2.” The documentation is itself a requirement as it helps all the stakeholders and consumers in understanding the requirements for the solution.

Where do these requirements come from?

All the requirements arise from a need. We need to understand those Business Needs or the Business Problem Statement. Unless there is a problem, we can’t think of providing a solution. A lot of analysis and research is carried on before requirement analysis to understand the problem. These involve feasibility study, knowing business terms and concepts, cost/benefit analysis, business strategy etc.

A Business Analyst (BA) starts with a broad and general description of what needs to be done and then starts working with key stakeholders to define the project scope (inclusions and exclusions), high-level business requirements, solution requirements, technical requirements and transition requirements primarily.

Talking about stakeholders, it’s important to know about who they are and how critical is their involvement in the project.

Who are stakeholders?

A stakeholder is a generic term for a person or group of people who are involved with the project (directly or indirectly) and have a say in decision making process of the project. They can be:

Executive Sponsor — Mostly concerned about funding of the project and high-level information
Product Manager — Make important decisions for the project and review & approve requirements
Project Manager — Prepares project plan, resource allocation plan, manages the execution of the project and works very closely with the BA (Business Analyst
Subject Matter Experts — Assists in defining project scope, works with the BA to define business rules, processes and user interface

There is a whole set of other roles such as Technical Personnel, Technical Writers, Quality Assurance Personnel, Database Administrators and others who can be important stakeholders in a project, depending upon the needs.

How stakeholders help with requirements?

Since each stakeholder plays a different role in the project, they have different requirements too. Sometimes, what emerges as the biggest challenge for a BA is to extract useful information from all these stakeholders that matches the preferences best with the client’s business. This is because each of them view the project from their own perspective!

To create best requirements for a project, identifying responsible stakeholders is important. There are many techniques available such as RACI matrix. Not all stakeholders are important for every project. It is primary task to identify the right stakeholders and their say in the decisions to keep things smooth in long run. (When all speak, it becomes real hard to reach to any conclusion).

How are requirements identified?

“The most difficult part of requirements gathering is not the act of recording what the user wants, it is the exploratory development activity of helping users figure out what they want.” — Steve McConnell

The process to identify requirements from the needs or conditions is termed as Requirements Analysis. A detailed analysis is critical to solution’s success or failure. It involves the tasks as analyzing, documenting, defining, validating, documenting and managing the changing requirements. There are different standards set in different organizations for the requirement analysis though the primary steps could be identified as:

Identify stakeholders
Requirements Elicitation — capture stakeholder requirements through various techniques such as interviews, questionnaire, joint group discussions, prototypes or use cases
Identify requirement categories — categorize all the gathered requirements into functional, non-functional, business, technical or transitional requirements
Analyze requirements — analyze the requirements whether they are clear, complete, unambiguous, consistent and testable
Requirements documentation — requirements are documented in various forms such as Business Requirements Document (BRD) to describe business requirements, Software Requirements Specification (SRS) to describe functional and non-functional requirements, Use cases and User stories (in agile context)

These recorded requirements documents are then collaborated upon to receive feedback from all involved stakeholders. Once the requirements match the needs for the project, it is important to take sign-off to freeze the scope of work and avoid frequent scope creeps at later stages.

Why are requirements important?

Per new research,

Success in 68% of technology projects is “improbable.” Poor requirements analysis causes many of these failures, meaning projects are doomed right from the start
Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their project
Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization

Requirements serve as the basis for the project plan and if there are inadequate or incorrect requirements, entire project will suffer at the end.

They are used as inputs into the design stages of product development
They are important input for verification process for the product developed
They represent what functionalities are necessary for the product

Excellent requirements leave no room for interpretation, confusion or omission of critical details and is easily understandable by everyone involved in the project.

Next time when you start with your project, make sure you have all your #requirements…clear and loud!

Stay tuned for more with requirement types, characteristics and more coming up!

This article was originally published by me on LinkedIn

Pablo Picasso and Scope Visualization

Paul Crosby — Wed, 07 Sep 2016 14:28:00 GMT

Scope – the last frontier. We are on a mission where no business analyst has gone before. To explore strange new diagrams and to have the project scope clearly understood. Extra credit to those who remember which TV show that was from! Scope and context are the number one reason business expectations about a project are not met, and projects fail.

Let’s face the reality. Projects today are more complicated. In this integrated and connected world of systems long gone are the days of the quick and easy change. Our organization’s architectural diagrams look like the tombs of Egyptian Pharaohs. Symbols and shapes connected by lines that fill the wall of an entire room. Even trying to explain the diagram to someone can take days.

Projects now require more involvement by more people. Our systems and processes are so complex and integrated it’s too difficult for one individual to understand them all. Stakeholders are flung across the globe speaking many different languages. Top it off with organization’s taking on hundreds of projects at the same time. Keeping track of each project’s scope and impacts to the organization are difficult to comprehend. It’s no wonder why understanding the context of a project’s scope is the number one reason why projects fail to deliver value. They lose sight of the project's vision and goals in our complex systems and processes. Everyone is one a different page. We wind up spending a lot of time trying to get stakeholders, sponsors, and team members to have a clear understanding of scope.

So it’s no wonder that scope and context are the number one reasons projects fail. How can you get an entire project team moving in the right direction? Not understanding the scope and context of a project leads to all sorts of time being spent on just figuring out what we are trying to accomplish with a project.

So how do we get everyone on the same page? By that, I mean the same page in the same book!

It’s time to visualize scope. Scope places the boundaries around where the entire project team will work. Bust out that context diagram. Getting a clear common understanding of scope and business expectations leads to better projects that deliver real value. Is that user story a complete representation of the project boundaries or scope? Maybe not. The EPIC or a bunch of user stories combined would be closer to the bulls-eye. A picture is worth a thousand words. Visualization of scope is worth its weight in platinum as it creates the vehicle to ensure a common understanding of the project scope.

Scope visualization isn’t just about a context diagram. That’s certainly a great tool, and I blogged about it previously. Don’t get me wrong – I love my context diagrams. Pushing the envelope a bit, I have used infographics to display project scope in place of context diagrams. In a recent server upgrade project, I was updating the operating systems and consolidating over 1,300 servers. Sticking 1,300 servers on a diagram was an exercise in futility. There just isn’t a big enough piece of paper to display them all. So I pictured things at a higher level. I presented each server farm as a farm – yup cows and red barn with Farmer Joe. The size of the farm was based on the number of servers on that farm. Server farms were in specific locations, so this gave the project team a visual representation of which sites were going to be impacted more heavily. All of this was based on estimates from doing a high-level scan. Remember context is high level.

In each barn was an icon that represented a group of servers. There were three groups: leave it alone, upgrade it and consolidate then retire it. I didn’t have exact numbers or server names at this point, but I knew the servers would be divided into those groups by talking with stakeholders. Servers were put into groups based on our best guess.

In the kickoff meeting, this was a great tool. Sponsor and stakeholders understood in the scope of the project. Yes, they wanted to know more. Everyone wants to know the details, but we were just starting out. Everyone walked out of the room with a pretty good understanding of the scope and estimated size. Many were surprised at the volume of servers in each farm. Overall the infographic did an excellent job of setting the stage for the project visually. All on one PowerPoint slide.

The idea of scope visualization is to present a single page to provide a high-level overview of the changes the project will make to systems, processes, and people. That’s no easy task. Taking the complex and making it simple is powerful. It creates a better shared understanding of the project.

The business wanted a global CRM solution, but all they got were pigeons and index cards. Yeah, that is why context is important.

Context doesn’t just talk about scope – it also sets business expectations about the outcome of the project. It’s important that all throughout the project to keep the communication channels open on what is happening with the scope and how the design is being implemented to meet the scope.

I take the concept of the context diagram a little farther than how most folks typically use a context diagram. You know me always pushing the envelope. Context diagrams usually explain the end state or the outcome of the project. They show the scope of a project outcome.

Building on a good thing, I like to build a context diagram of the current environment at a high level. Even at a high level, I’m often surprised at how differently stakeholders, sponsors, and team members view the current state. It’s a great tool to get everyone on the same page for the starting point. Having everyone on a different page for what we currently have will cause a few issues down the road in understanding the final destination. Knowing where you are starting from is a powerful thing when to explain where you want to end up in the future state.

Taking this concept even a bit further (and perhaps more uncomfortably) into the desired state. Not many projects look at the desire of the stakeholders and sponsors. The desire is stated in the project request form or project charter. The sponsor and stakeholders put together a vision of the expected outcomes in these documents. A context diagram of the project charter or request which elaborates the vision is a powerful thing. It ensures what is being asked for is understood.

Don’t re-invent the wheel. Many times I take the current state diagram and just highlight the areas that are changing. Use color to highlight the add, modify or removes based on the context diagram for the current state. Color visually explains where the changes are visualized to occur.

Now you may think I completely lost my mind at this point. Fear not I’m taking a step even further. I take the context diagram that shows the desired state (based on the project charter or project request) and determines what is feasible. Everybody wants it all but the teleporter to zap you across the globe for a break in Paris hasn’t been built yet. Reality always steps in and dictates what is feasible. Taking the context diagram I will highlight the areas that are NOT feasible. It’s a great way to level set the expectations of the sponsor, stakeholder and project team members.

So when in the project life cycle does all this context stuff happen? Ideally, it should happen before the project starts at a very high level. Wouldn’t it be great to start a project where everyone understood and was in complete agreement about the project outcome? You can bet it would save a lot of time running around trying to get everyone on the same page. Typically, the context is set at the start of the project.

As you move through the project, more and more understanding is acquired. Details need hammering out and there is ALWAYS change to the project. Has anyone ever worked on a project with absolutely zero change? If you have, you are leading a very charmed existence. I’m jealous. Context diagrams can help evaluate how a change would impact the project. So forget about laminating them and hanging them on the wall. They are living breathing documents that will change throughout the life cycle of the project.

The pitfall is that architects and others might expect diagrams that show the smallest of components. Don’t fall into that pit. Your job is to communicate the boundaries clearly but not make it so complicated a rock scientist from NASA can’t figure it out. Detail is important for design but scope context requires things to start at a very high level and be decomposed into more information. Context is simple with enough detail to make it clear.

Break out your inner Pablo Picasso and get creative. Find a way to display context or scope in a visually appealing manner. Color can help bring greater clarity. Highlight areas in different colors to bring focus to them. If a system is risky or substantially impacted by the project scope, highlighting is a technique to denote that risk. Black & White isn’t your friend. Studies have shown that color diagrams – even with a small amount of color – are more memorable.

Check out Bob’s blog for more good stuff on business analysis and sign up for our newsletter today. Bob the BA offers the Badass BA workshop and Enterprise Analysis workshop which covers this technique in more detail.

8 Ways to Be a Badass Business Analyst Employee

Paul Crosby — Wed, 07 Sep 2016 14:23:00 GMT

Being a badass isn’t about intimidation or trying to be something you simply are not. It’s about knowing who you are and using your strengths to drive forward. So let’s look at a few of the ways to be a badass in business:

1. Passion for Your Craft Is a Powerful and Infectious Energy

Showing passion for your work in always willing to learn more and explore new ideas in your profession shows you are a badass. A badass isn’t afraid to learn something new about their craft. Always be willing to step up to the plate and show what they are good at performing. Sitting back and doing just the expected is not the badass way. If you are amazing at drawing diagrams, then use them frequently in your work.

A few years ago I was managing several projects. Things were not going all that well on these projects, and I knew something needed to be done to get them on track. Holding up the schedule and pointing at it wasn’t solving the problems we were facing. I decided to explore different approaches and ideas by contacting others outside the company for their advice and doing a little reading up on handling scope problems in projects. I learned a lot of scope management techniques as a result of that exercise and was able to apply them to my project. My boss at the time noticed I went out of my way to figure out new approaches, and I was fearless in learning new techniques about my craft. By learning and stepping out to explore new ideas I was able to move the project forward and save the project from failure.

2. Keep Positive

Nobody likes a negative person constantly interrupting, jumping to conclusions and always complaining. Keep a “we can do this” mentality even in the toughest of times. The measure of a badass is in being able to be calm, think clearly and project positive possibilities. When the whole world is crashing down, don’t be the one saying “Well that figures.” Instead be the one saying “This isn’t the greatest situation, but we have some great opportunities here to make positive changes.” See the good in situations where others cannot. Be the person that says “I’ve got a few ideas that might help in this situation, and I would like to bounce a few of them off of you.”

One of the toughest projects I faced was working with remarkable requirements, but a development staff that either didn’t want to or just could not fulfill those requirements with the current system in place. The team quickly got very negative at all the challenges that we were having in development. Everyone’s attitude soured and nothing was getting accomplished. The project was on its way to failure. So I threw a pizza party. My entire team thought I lost my marbles, and it was time to call the men in white coats to pick me up. Pizza does wonders for putting a team in a better mood. I told the team I understood the situation was bad and acknowledged that the company wouldn't accomplish anything without their skill sets. I purposefully turned the conversation from a negative (What is going wrong?) and made it positive (What ideas do you have to make it better?).

This was no easy task. I had to work very hard to move everyone’s attitude toward the positive after months of being in the negative. I was direct in telling them “Nobody wants to work on a negative team – it sucks. What can we do right now to make this team more fun and productive?”. After that hurdle had been cleared, it got easier to involve everyone in making team changes and design changes to the project. I kept telling myself that no matter what happens I will remain positive. The team’s attitude evolved over time. Many team members and company leaders repeatedly said that they could always count on me for being positive and finding solutions to problems.

3. Know Your Craft and Tools

A badass doesn’t just stop learning the basics of their craft or tools. They are constantly expanding their toolset and keep current about their craft. It’s too easy to get comfortable and begin to feel there is nothing more to learn. A badass grabs any opportunity to learn new things.

In my past life, I was at a company where I was pigeon-holed. I did such a good job at data warehousing and reporting that no one wanted to let me try anything new or different. Damn, I was bored out of my mind because every day was the same thing over and over. Sure I was learning new things about data warehousing and reporting, but I never stepped out of that area into other areas. So I forced the issue a bit and shoehorned my way into a call center application. It made sense for me to pursue it because that new system would be feeding the data warehouse. I went a little further than just worrying about data and started moving into user interface design and workflow for the new call center application. It was a great experience to use the knowledge I had in data warehousing and reporting to build better user interfaces and business processes. After the project had been finished, I was seen as being useful in business process as well as data warehousing. The door opened, and I got the chance to work on a whole new set of projects. Don’t be afraid to step out of bounds – you just might be valued for it.

4. Make Life Better for Others

A badass knows that improving the lives of their team members by continuously being focused on improving the way things are done is important. Being innovative to solve problems the team is experiencing in the day to day operations is just as important as solving project problems. Process improvement is powerful. A badass understands it’s not about single glory but helping others to achieve great success.

You always hear “It’s not my job” especially in large companies with well-defined roles. A badass looks for ways to improve the working conditions and tasks their team performs. It can be a simple as creating a library of past project documents that can be reused or finding a new way to perform time reporting that is easier. Whatever it is, a badass is looking for ways to improve processes at every moment and isn’t afraid to suggest well thought out changes.

5. Know Thyself Well

Know thy strengths and know thy weaknesses. A badass is aware of their strengths, and they know their weaknesses and limits. In today’s corporate culture, we focus on weakness. By focusing entirely on weaknesses, performance appraisals have become more like firing squads. A badass knows to play to their strengths and to engage others to help them out with their weaknesses.

There are certain things I have discovered I’m genuinely bad at. Anything that involves molding clay into an object is bound for disaster. Both of my skiing trips ended in an uncomfortable tree hugging. In business I know I’m a driver – be quick, be bright and be gone. It wasn’t until half way through my career that I realized how that impacts others who are not drivers. By understanding how I lead and act, I was able to soften my approach and be more collaborative with others. My driver mentality is a strength that others recognize. I can snow plow through massive amounts of data to give clear direction. I communicate quickly and concisely on projects.

Play to your strengths at all times. If you know you are weak in an area, then go out and find someone who is strong in that area to balance you out. If you get the chance to put teams together, look at each others strengths and weakness to balance them all out. Forget about finding that perfect all around team member without weaknesses. They don’t exist.

6. Don’t Always Say What They Want to Hear

Being a butt kisser or yes man is not the path of a badass. If you are always saying what others want to hear from you, they will never fully trust you because they can’t tell if that’s what you honestly believe or if you are just being a parrot and repeating everything back to them. A badass understands that conflict is part of life, and sometimes you are going to have to say what doesn’t want to be heard.

The trick here is saying it without being annoying or a jerk. If there is an elephant in the room, then say there is an elephant in the room. A badass knows that hiding the obvious doesn’t make it go away but rather gives it greater power. Address it quickly and directly. Forcing the issue is a one-way ticket out the door. Follow the “Toot, Toot and Salute” rule. Bring it up once and if there is no response or disagreement then re-group your thoughts. Bring it up again and if there is still no response or disagreement, then accept it and move forward.

7. Ask Questions, Challenge and Dig Deep

No one likes to be challenged. It puts them on the defensive right away. A badass understands that challenging an idea is an art form and that challenging helps bring deeper understanding and meaning. A badass knows that without asking questions and digging deep, the entire problem cannot be understood fully.

Nobody likes to feel they are being interrogated. Be fearless but considerate in digging deep. Verify your thinking and dig deeper with “Help me understand” questions. Share what you have learned to validate it. Be appreciative of the different perspectives and gather them all up to see the greater picture more clearly. The most significant problems I created for myself was making assumptions and never validating those assumptions. You may not be able to validate or challenge at that specific moment. Write it down, reflect on it and determine if you need to challenge it. Challenge appropriately and thoughtfully. Step back and schedule a challenge at a later time.

8. Lead Even When Your Job Title Doesn’t Say Leader

A badass leads even when it isn’t in their title or role. They had the initiative and don’t shy away from leading in their craft. They don’t wait for someone else to schedule the requirements meetings, they step up to the plate and schedule them.

In the many times, I have played the role of the business analyst I’ve stepped outside my role a bit. I’m probably more comfortable with that then other business analysts in that I have been a project manager. My favorite is when I’m told how long it will take to gather requirements. You know those meetings were without being consulted the project manager has decided how long you as the business analyst will take to gather requirements and complete the design. When I’m in the business analyst role, I often will put together a requirements work plan outlining the steps that will be taken to elicit requirements and build the design. I review it with my stakeholders, project team and sponsors. This runs face first into the project managers desire to create and control the schedule. By gaining common agreement on tasks for the requirements and design process, the schedule can be more reasonably created which in turn helps the project keep to its timeline and budget. Is there a negotiation? Oh yeah – there will be lots of negotiation with the project manager, sponsors, and stakeholders on what will be done and what won’t be done. Step up to leading the task and schedule you will be expected to adhere to for the project.

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

All requirements are important!

Praveen Udupa — Wed, 18 May 2016 02:57:00 GMT

I was running a meeting with a few stakeholders. I was imploring them to indicate the relative importance of requirements, but was hitting a brick wall; they kept insisting, "They all look the same to me. All requirements are important. They all are must-haves."

I tried to reason with them multiple times over. There are just too many requirements, and cannot possibly implement all of them in the available time and/or budget. But they kept insisting that all requirements were indeed important.

I thought to myself, “Why are these people being so difficult? Why are they deliberately feigning ignorance?” I literally felt like tearing my hair out!

Have you been in this situation? I bet you have. Why is prioritization such a hard exercise? There must be a better way, right?

Let's rewind a little bit and review how we usually begin a Requirements Prioritization meeting: "Thanks for accepting this meeting. The purpose of this meeting is to prioritize the requirements. We are going to use the MoSCoW technique. Let us walk through each of the requirements and collectively decide whether this is a M, S, C or W."

Sounds familiar? If not exactly as stated above, it could be some flavor of the above. Instead of M, S, C or W, it could be some other rating mechanism. But, for the most part, the spirit is essentially the same.

My hypothesis is that, with the above expectations, stakeholders truly are not able to differentiate relative importance among requirements. They aren’t being difficult at all; they honestly cannot prioritize. Let me give you an analogy:

Imagine being in a corporate conference room. What can you find in there? Whiteboard, video con equipment, large table, uniform looking black chairs around the table, etc.

Suppose I ask you to arrange the chairs around the table in the decreasing order of blackness, what would you say to me? I imagine you would say, “They all look the same to me.” Exactly the way requirements appear to the stakeholders – all the same.

Suppose I give you a pair of glasses. Not any ordinary pair of glasses, but one that has spectrograph capability, and a display on the top right corner. When you wear this glass, and look at any object, a graph of various colors on the object along with their intensity represented numerically is displayed. Now would you be able to do arrange the chairs in their decreasing order of blackness? Sure you would!

Few questions to ponder over:

You weren’t initially able to arrange the chairs in their decreasing degree of blackness. Is that your fault? Does it indicate your weakness? Or does it point towards my weakness of not knowing how to enable you to do that activity?
Is it the stakeholders’ fault that they aren’t able to prioritize the requirements? Or is it my drawback as a BA that I wasn’t able to get them to “see” the relative importance among requirements?

Think it over. I would love to hear your comments. Let’s talk and engage in a productive discussion.

Meanwhile, in my next blog, I will write about the various glasses that you can provide to your stakeholders to get them to truly see the relative importance among requirements.

BABOK v2 - End-to-end data flow diagram analysis can highlight issues

Alan — Thu, 10 Jul 2014 01:20:00 GMT

As part of preparation to sit the IIBA CBAP exam, I wanted a one page summary of the overall BABOK flow. The first step of creating a summary matrix showing a derived master list of documents (e.g. Inputs + Outputs) versus the process that creates or uses it was interesting, but not entirely helpful.

By using the matrix to create an indicative data flow type diagram, that helped to better understand the overall end-to-end process documented in the BABOK.
Note: Clear stakeholder information was not available so a Business Process type Model was not possible.

The data flow type visualization technique is very useful:
1. It is an additional visual means of communicating complex information for people who struggle with understanding just text.
2. It quickly shows the flow of information between the various processes
3. The data flow diagramming conventions help to highlight issues. E.g. No clear sources or uses of specific deliverables, redundant and reverse flows etc.

This is also timely given the review of the Draft BABOK v3 material that has been requested and that closes on July 11th.

3 Tips for Obtaining Requirements Sign-off

Stephanie Famuyide — Fri, 28 Feb 2014 18:28:00 GMT

Sign-offs are a sign that stakeholders agree with and approve the requirements that have been elicited and documented. There are multiple reasons why BAs seek stakeholder sign-offs and in some cases, it is not always clear whom it benefits.

While some methodologies like Agile do not involve a formal sign-off, requirements sign-off does add value. Here are 3 quick tips to help you get the sign-off you need:

1. Ensure that stakeholders understand the Requirements Specification Document (RSD)

Though you might be lucky enough to get a stakeholder to sign off on the RSD without understanding its contents (some people do sign documents without reading them), the ethical thing to do is seek their understanding and cooperation before asking them to sign. This approach is more likely to have a lasting positive effect on the project.

Analysts should avoid insisting on getting sign-off from stakeholders on RSDs that the stakeholders have not read, or have read but do not understand. They should instead, seek to get their understanding and commitment.

Key Takeaway: If you are planning to get a sign-off on your RSD, make sure stakeholders understand its contents. Discuss the contents of the document, take down their concerns, answer their questions, seek their opinions and let them feel involved. This is the ethical thing to do and it would help to build trust between you and your stakeholders. Lastly, you will get a “knowing” sign-off and not one that is given in ignorance or under duress.

2. Avoid spending an excessive amount of time getting the RSD signed off.

One disadvantage of sign-offs is that they take time. Most times, Analysts have to invest valuable company time in explaining the RSD to stakeholders, after all, they should understand the contents before signing off on it. This can introduce significant delays to the project, especially when stakeholders are difficult to locate or are in a different geographical location. How does the analyst justify placing lesser priority on other business analysis tasks to chase stakeholders' approval of requirements (signatures)?

Obtaining a sign-off becomes even more challenging in situations where stakeholders have not requested for the change. How does a stakeholder sign off on a requirement that did not come from him or her? The fact that a stakeholder has been designated as “process owner” does not signify that he or she is ready for the change.

Change projects may become necessary due to technical reasons, regulations or requests from other departments. Unless the benefits are obvious or the implications of signing off on requirements are mild to non-existent, don't expect stakeholders to give you an easy time.

Key Takeaway: Get all the relevant stakeholders involved as soon as you start the project. The more involved they are from the beginning, the more cooperative they will be when it's time for sign-off. Sign-off is also easier to obtain when requirements have been developed and documented in a collaborative fashion (using wikis, for example). In addition, requirements review sessions can be held to get the RSD signed off on time.

3. Avoid idle time while awaiting sign-off

In some organizations, developers do not write a line of code until requirements have been signed off. A delayed sign-off process can create idle time for developers (and analysts) who have been hired to complete the job. In some cases, developers would have already started the work before the requirements are signed off. This can be risky, however. Cancelled projects are only one consequence, though one can argue that the fact that the RSD has been signed off does not mean that the project cannot be cancelled.

Key Takeaway: Communicate constantly with stakeholders to ease the sign-off process. Where sign-off is not forthcoming, it's important to start asking yourself how important the project is to the stakeholders. Escalating to a higher authority may encourage the desired behaviour.

When sign-offs are sought without political undertones but with the right intentions, there are certainly benefits to be had. The sign-off process should be approached as an opportunity for discovery, which allows stakeholders to ask questions and get clarification on their areas of concern. A huge benefit to obtaining sign-off on requirements is that it is an indication that stakeholders are aware of, and are committed to seeing the solution live and in action.

Stephanie Famuyide, CBAP is a Business Analyst Practitioner, Blogger and a Lover of Life. Visit her Blog, Business Analyst Learnings for templates, practical tips and timely articles on business analysis.

5 Pitfalls to Avoid in the Requirements Development Phase

Ken Young — Wed, 07 Aug 2013 17:37:00 GMT

Developing requirements is a process with many moving parts. It involves aligning multiple stakeholders from different areas within an organization to determine what must be developed to fulfill a business need. Because it is a process, there are a number of factors that can cause the process to break down and lead to the development of faulty requirements:

Lack of Clear Objectives: Every application is built to play a role in some larger business context. When the business client is unclear in communicating the purpose of the application, or stakeholders lose sight of the application’s business context, the requirements in all likelihood will “miss the mark”, lacking essential functions and including unnecessary features.
Lack of Stakeholder Involvement: One of the biggest challenges in the requirements process is getting stakeholders to invest their time, over multiple elicitation sessions and then multiple review cycles, to carefully examine the requirements and provide feedback. When stakeholders are inaccessible, or are not invested in the project during the early phases, requirements flaws can remain undetected until after development begins.
Inconsistent Information Gathering: When developing complex applications, a team of business analysts will often be involved in gathering information. When inconsistent elicitation approaches are used to gather and record information, it becomes difficult to categorize, prioritize, and ultimately reconcile the often conflicting needs of different stakeholders.
Information Overload:The traditional reliance on recording requirements in long, unwieldy text-based documents not only leads to misunderstanding, but also contributes to stakeholders’ lack of involvement in the requirements development process. Using long text-based documents makes it hard for end-users and business clients to picture how the application will behave, and what may be missing.
Poor Expression: To review requirements, and ultimately build applications, all stakeholders, from the business client and end-user to the application developer and tester must be provided information in formats and using language that each can understand. Delivering information in forms that don’t take into account the different types of stakeholders inevitably leads to flawed requirements and the development of applications that don’t fulfill the objectives of the business.

When developing requirements, check to ensure that you have avoided the pitfalls above and your requirements are much more likely to be complete and effective.

Ken Young works for Blueprint, The Requirements Company. He can be reached at ken.young@blueprintsys.com.

How to convince stakeholders of BA value for the first time?

Lee Grinberg, CBAP, PMP — Fri, 21 Jun 2013 13:46:00 GMT

In my previous posts I outlined how I was able to succeed being the first and only BA at a company and the importance of establishing trust between you and the stakeholders.

So you're the first BA at a company. All are looking at you and thinking what can this person do for me?

Good question. What can you do for them?

Show them how your contribution will make their life easier!

I'll tell you how I handled this challenge. I was brought in to write functional specs based on business requirements. The business requirements were good but not complete. The IT folks were afraid that key use cases were missing.

I took the following steps:

Created a context diagram (first one in the company) to show them what scenarios may be missing
Created use cases from the business requirements
Reviewed both with the SMEs. This uncovered many gaps not covered by business requirements

Once gaps were uncovered, the people writing the business requirments were relieved to know the gaps were identified early in the process and not in a later (embarassing) stage. I made their life easier and this was appreciated.

The next steps were around design:

Wrote a detailed functional spec outlining database and functional changes
Clearly wrote out testing scenarios

So what, you may be thinking. After all, this is what BAs do. True, but remember, I was the first and only one in the company so no one was convinced of the value of a BA.

The result of design was that developers were relieved to know they didn't have to have lengthy conversations with the end users about functionality.

The key concept again is to make their life easier!

Once trust is established, however, you must prove that you can benefit the stakeholders.

A Call to Every BA: 8 Mistakes to Avoid in Writing Requirements Specification Documents

Stephanie Famuyide — Thu, 04 Apr 2013 06:53:00 GMT

According to the Strategies for Project Recovery report by PM solutions, based on 163 respondents, $74m invested in projects annually are at risk of failure. The report identified one of the top 5 causes of project failures as unclear, non-prioritized, contradictory, ambiguous and imprecise requirements.

Information like this is quite disconcerting, considering the fact that it is the responsibility of business analysts to elicit, manage and communicate requirements. As a first step to rising up to the call of producing high quality requirements and turning the tide of ICT projects, this post points out the tricky nature of requirements and mistakes that BAs can avoid when compiling requirements specification documents.

According to the 1986 paper by Parnas & Clements, “A Rational Design Process: How and Why to Fake It”, designing software in a rational, error-free way from a “complete” requirements specification document is like searching for the philosopher’s stone. I once wrote an article: Agile Software Development Methodology: Remedy For the Incomplete Requirements Specification Document, based on my experience, on how difficult or should I say impossible, it is to write a complete requirements document.

So, what exactly makes writing requirements so tricky? Here are 6 factors to consider:

Stakeholders do not always know what they want and when they do, they’re unable to tell us everything they know. This can happen where a stakeholder assumes that the analyst already has information they don’t have, where the stakeholder hoards information, where the stakeholder is just unable to put into words exactly what they want due to communication gaps or where the stakeholder is unable to anticipate everything he needs due to the simple fact that he is human.
Even if we knew all the requirements to get started, additional but useful facts only become obvious after we have started the design work and in some cases, when the system is being tested. As we encounter new information or product defects, analysts often need to go back and refine the requirements while minimizing lost work.
There are too many details surrounding the development of a system that humans are unable to comprehend. This is where bounded rationality comes in. Human beings, no matter how intelligent they are, are faced with 3 main constraints: 1) Only limited and often unreliable information are available to develop requirements 2) the human mind is limited in its capacity to process the available information 3) Most projects are time-bound, thereby shortening the time it takes to fine-tune requirements
External factors, over which we have no control, can cause requirements to change
Even where concerns are separated, errors in stating or representing requirements can still be made since it is handled by humans
We are often influenced by pre-conceived ideas and notions (from lessons we’ve learnt, cases studies or from formal institutions), which may cause us to misrepresent requirements along the line.

Bearing all these in mind, all we can do is try. Parnas & Clements suggest that we should still create requirements specifications documents as if we had followed a rational process

So, what exactly are requirements specification documents?

In clear and simple terms, a requirements specification document outlines what the software is expected to do. Between the users and the analyst, an agreement must be reached on what actions users can perform and what responses they can expect to receive from the system. This is only logical. It serves as a contract between the analysts and the customers.

Why would you need one?

Requirements documents play a significant role in the design process and are used as a reference point for system design throughout the software development lifecycle. How would developers know what to develop without one?
It’s a document where requirements are recorded and reviewed for approval – the scope of the project is explicitly contained in the Requirements Specification Document.
It prevents making spontaneous decisions about requirements as the project evolves. Programmers should not be the ones deciding what is best for users
To avoid duplication and inconsistency. Programmers or stakeholders may ask the same questions repeatedly and receive inconsistent answers each time. Having a central point of reference will help to clarify grey areas throughout the duration of the project
A software requirements document aids accurate estimation of the amount of time and resources needed to conclude the project
It provides insurance against personnel turnover. Requirements will not exist in one person’s head and knowledge of user requirements can easily be transferred to other projects even when analysts or developers leave the team
Provides a basis for writing and developing test cases

On writing better requirements specification documents, what is the way forward?

While there are no excellent ways of writing the requirements specification document, there are some mistakes we can consciously avoid.

Poor Organization
Avoid poor organization by defining the structure of the requirements specification document before you start writing. Each requirement should be defined in one section and one section only.
Confusing/Inconsistent Terminology
Use a glossary containing the definition of all the terms used in the requirements specification document; this will ensure that all the members of the team understand what the document is about.
Boring Prose
Don’t use plenty of words where you can use a picture or a formula. Also, repeating facts in different sections of the documentation increases the burden on the reader and causes inattentive reading which in turn may lead to undiscovered errors. Repetition of requirements in various places on the document would also require maintaining different sections of the document when changes need to be made. The resulting read should be detailed and precise but not boring.
Myopia
Requirement Specification Documents should be written clearly without assuming that readers have a prior understanding of the requirements. This would prevent misunderstanding further down the line. All assumptions should also be clearly stated. Areas where information is not known or is likely to change should also be highlighted.
Solution-Bias
Requirement Specification Documents should not describe solution ideas or contain any implementation details. It should describe only “what” the business needs and not “how”.
Requirements Verification
Requirements should be verified with users again and again. Since requirements cannot be gathered all at once, they need to be evolved. The document should be continually reviewed whenever changes are made and updated whenever requirements are discovered.
Presentation
Presentation does matter.

Use descriptive titles
Use bullet points and short sentences to assist readers in staying focused.
Use the active voice in writing requirements
Use a table of contents so that readers can navigate the document easily
Avoid the russian nested doll effect – Requirements within requirements. Always break down parent requirements and never use “and/or” in your requirements documents – this would mean that several requirements have been nested together in one and can easily lead to confusion.

8. Remember the acronym FUC4TM
Requirements should be

Feasible
Unambiguous
Complete
Cohesive
Consistent
Correct
Testable and
Modifiable.

How else can Requirements Specifications Documents be improved?

Join the call and share your thoughts.

Stephanie Famuyide is a business analyst blogger that blogs about all things business analysis. Visit http://businessanalystlearnings.com where I provide practical tips you can apply on the job.

ISO 25010

Adriano Comai — Fri, 20 Jan 2012 09:36:00 GMT

ISO 25010, "Systems and software engineering - System and software quality models" was published in March 2011.

The ISO 25010 standard defines 2 broad non-functional categories of requirements, "Quality in use" and "Product quality", articulated in 13 characteristics, many of which are further subdivided into sub-characteristics. This new standard replaces the previous ISO 9126 standard, heavily used both in requirements management and in testing.

To find out more, see my pdf presentation.

Five New Year’s Resolutions for Requirements

Seilevel — Fri, 14 Jan 2011 21:38:00 GMT

It’s that time of year, where our thoughts turn to the holidays…the holiday parties, the shopping, the lights, visiting with family! For many organizations, the end of the year tends to be quiet on the IT front, for no organization wants to risk introducing problems into their production environment at year end.

So as I look back at this year on what was accomplished, I tend to do a mini-retrospective on my year…what went well, what did not, and what can I improve? Thus looking at those items to improve, I’ve come up with a list of New Year’s Resolutions to focus on for next year:

Use the ROM – Requirements Object Model

Understand what the business problem is trying to be solved for any project that I am working on. This can be difficult to get on any project, but essentially, every project should be attempting to solve some business problem. Usually these problems are rooted in money.

Once the business problem has been identified, the business objectives can be defined. And from there, the strategy to meet those objectives can be defined.

The benefit of understanding the business problem is then you are developing a solution that will provide a return on investment. No one wants to do a project just because, there should be a purpose and it should be valuable.

Write Clear Concise Requirements

Of course I always try to write clear, concise, testable requirements. But what seems to be clear, concise and testable to me may not be in reality. So I always consider this an area of constant improvement.

How can I ensure that I am writing clear, concise, testable requirements? Reviews are always a great idea. Get another set of eyes on what you have written. I like to get a peer to review my work before sending it off to my client, and preferably, someone who is not very familiar with my project. The less they know the better. For if they can understand the requirements, and then I feel like I have done a decent job in getting them document.

But these peer reviews do not take the place of reviews by the business. They are the ultimate authority, and definitely need to be done to ensure correctness and validity.

One final word on this topic and it may sound silly to state this, but I see many mistakes made because of it: spell check does not replace proof-reading. Spell check can definitely help you ensure that the words are spelled correctly, but it cannot help you ensure that you have the right words. I’ve seen embarrassing notes go out…the words were all spelled correctly…but one wrong word could mean big trouble!

Ensure Better Transparency

Transparency means being as clear and upfront with regards to the progress and status of your project. One way to help ensure transparency is to provide status reports.

I try to send frequent and consistent status reports help provide information on how the project is progressing to those who need to know. These reports should include information such as what was accomplished that week, what was not and why, what is planned for the next week, and any risks or issues that have arisen. This information helps me keep a running record of what has happened in the project, and can help refresh memories when people have forgotten what has been done.

They do not have to take long to create, especially if you create a template, and if you are consistent with sending them out, they become part of your routine.

Do Requirements Traceability

I try to ensure that all requirements map back to the stated business objectives. This helps ensure that no business objectives have been missed, but also helps prevent scope creep.

While we all know that traceability is a good thing to do, it is laborious and tedious to do, especially outside of a requirements management tool. As requirements are written, reviewed and edited, maintaining traceability can be very difficult. I try to wait until later in the requirements definition process can save some work; however, I have to be careful about waiting too long. If I wait too long, then I may miss a chance to add missed requirements, or to prevent scope creep.

Use Models

Finally, I need to use various models to describe requirements. There is no one model that can demonstrate a set of requirements fully and completely. A combination of several models allows the requirements team and development to see the requirements from several different perspectives. It helps us gain a full understanding of what is being requested, and helps ensure that there are few misunderstandings.

While it may be easy to say “use models”, it can be a challenge to get an organization to do so. People get comfortable with their current process, and can be reluctant to change. They may resist the introduction of anything that is perceived as more work. To get around those that are resistant, I try to constantly show how the model s adds value. I remind other business analysts and product managers ultimately, the models are not for them…they are for the business to confirm their requirements, and they are for development to get a full understanding of what is desired. We are in the business to help others clearly define what they need, and to help deliver those results.

Finally, I would like to wish all of you healthy, safe and happy holiday season!

Want more on requirements and requirements models? check out our other posts.

http://requirements.seilevel.com/blog/

Is Traceability Possible Without a Requirements Tool?

Seilevel — Mon, 20 Dec 2010 05:07:00 GMT

I have spent the last year and a half working on an enterprise software solution development effort where we do not use a Requirements Management tool like Caliber or Visual Studio TFS. Our requirements are created in Word using standardized templates and distributed to Development and Test teams for consumption.

Test cases are written in Excel and tied to the requirements in the documents. In general, I would have to say that coverage is good but not complete (I know this anecdotally since there is no good way using Excel and a bunch of Word documents to know for certain). In theory, a failed test case should mean that a requirement is not satisfied and pinpoints a missed feature or requirement.

This system breaks down totally when it comes to Change Requests that are created during the course of the project. Change Requests are entered directly into a defect tracking system. Change Requests are usually supposed to have detailed requirements associated with them but in practice the quality of the supporting documentation has varied widely. So, Change Requests have little to no systematic traceability associated with them. This is not to imply that the Change Requests are poorly implemented. Just that doing any kind of systematic tracing exercise against them is near impossible.

The key problems I have found with using Excel to perform traceability are as follows.

1. Forward traceability from Business Objectives or High Level Features to specific requirements is very difficult to do and in many cases is just not practical.
2. Managing requirements as they change is very difficult to do. You could have false positives where the spreadsheet tells you there is good coverage without realizing that the underlying requirement itself has changed.
3. Managing multiple tests for a single requirement because very difficult. For example, if a single requirement has to pass 3 test cases for it to be considered fully implemented, the spreadsheet approach becomes error prone and hard to understand very quickly.
4. The spreadsheets themselves become unwieldy as multiple requirements and tests are entered. The volume of data becomes hard to manage and consume.
5. Reporting becomes a hit and miss process. It requires a lot of manual effort, is time consuming and error prone.
6. Requirements that do not start life in a requirements document (Change Requests) are seldom tracked as rigorously as standard requirements.
7. Historical analysis is very difficult to do. On projects that last several years, digging up an old Excel spreadsheet to determine if specific requirements were implemented or not a year ago can easily become a week long exercise in futility.

So what then is the answer to the question I posed at the beginning?

Excel is fine for small projects but larger enterprise grade efforts require a specialized requirements tool with good tracing features.

The odds of performing good traceability on your project are significantly improved when using a requirements management tool. There are real costs associated with unimplemented or improperly implemented requirements. A good tool gives you a better chance of catching these kinds of errors with good traceability features. So, when considering a tool to manage your requirements, do not overlook the quality of their traceability features.

For more check out our blog: http://requirements.seilevel.com/blog/

By Abadri

Square pegs, round holes - why non-funcs are really not stories

FergalMcGovern — Fri, 17 Dec 2010 21:11:00 GMT

I've been blogging lately about a couple of topics pertaining to 'agile' methods. Along those lines, I wanted to consider one suggested practice that I think is worth reflecting on, that is; the treatment of NFRs (non-functional requirements) as stories.

Let's draw back for a moment. Regardless of process approach, be it traditional or agile, poor treatment of NFRs is one of the highest risk areas in IT delivery. For anyone who has been involved in even a half-way serious type of project, lack of adequate NFR consideration will royally bite you in the bum. In my experience, it is probably the single biggest cause of lost sleep, likely I suspect accounting for the highest rate of ulcers for project & program managers. This applies to stakeholders at all levels, from project managers to executives. Executives as they realise in horror that the $70 million integration project due to go into production in 2 months time is behind and is not scaling according to plan and the business is looking for a release date or that the production system is down periodically for long spells due to scaling issues.

Many stressful roads lead back to NFRs and if the NFR horse has bolted on your project, get ready for some serious stress. That said, let me get back to the point of this post, NFRs as stories.

So, I'd like to challenge one of the sacred cows for some in the agile community; namely that 'everything is a story', including NFRs.

A number of blog posts argue for representing NFRs as stories, including this one. Not everyone in the agile community agrees. The excellent Scott Selhurst blog is a notable example of extremely balanced thinking in that regard. Tom and kai Gilb have a lot to say on the matter here irrespective of whether you're in traditional or agile settings or a mix.

Let's get a definition or two out there, so we're on the same page. Firstly what is an NFR? I will take the definition I first spotted in the 'HP Fusion' process oh about 18 or so years ago, that is we have basically two types of NFRs; Qualities and Constraints. Qualities are generally very clearly measurable and represent things like performance, uptime, data load etc, the classic 'ilities'. Qualities will tend to be associated with strands of functionality or with the system as a whole. Constraints tend to be exactly that, statements of constraint, for instance 'we must support IE 6' (at VisibleThread this particular one pains me considering the variations on service pack OS etc. but as we do have customers on IE 6 we need to satisfy this constraint). An example of a second constraint is: 'Must have a legal disclaimer on every page of the web interface' or 'we must code in Java on JDK version x.y'

You may not agree with the qualities or constraint delineation or have differing views but that's fine, work with me, whatever you choose to call them, most people agree that both styles of NFR exist, regardless of your definition or terminology.

Let me offer a few reasons for why agile analysts & team members should consider avoiding representing NFRs as stories.

Communication: NFRs often have a heavier impact than stories on core design foundations. Ask any tech architect or design lead for war stories on challenged projects they know and you are highly likely to be able to attribute the issue to lack of ability to satisfy one or more NFR as it's root cause. Therefore the act of calling out NFRs as something that is not a story is of immense value from a communication standpoint. As an architect seeing a clear delineation of NFRs (particularly the qualities) from stories helps identify incompleteness.
Cross-cutting scope: NFRs tend to come in two broad 'namespaces', those that apply universally across the project and those that may be associated with 1 or more strands of functionality, (a story in Agile-land). Handling both types of NFRs as stories does not easily allow us to map 1 NFR to multiple stories
Elicitation: NFRs are by their nature, the most difficult class of requirements to elicit. Having explicit categorization and expectation that not only will they exist, but that they are measurable and verifiable forces serious questions to be addressed upfront in iteration-0. By forcing a clarification of measures early in the process around NFRs such as security or scalability, key design and architecture inputs may adjust trajectory
Quality type NFRs are assertions with properties: NFRs are not functional in nature, stories are a functional artifact. Whilst it can be a useful device to use a story persona as a way to drive elicitation of NFRs, in normal complex systems where you need to put in multiple additional associated attributes; boundary values, max, min, mean, load etc., a tabular format tends to be more comfortable for people to read & document.
Testing: Having 1 NFR, particularly Quality oriented NFRs, represented in tabular fashion with each row outlining testable measures for instance, leads to a better ability to conduct test planning. It also means that we can incrementally knock off specific rows as part of particular sprints, yet have the more general NFR in place so it's pervasive and front of mind. Even the best intentioned team members may forget the NFR obligation unless it's kept front of mind.
NFR Lifecycle: Non-trivial NFRs in many cases can affect multiple sprints and have a life-cycle that lasts far longer than a 2 week sprint. Artificially closing them and re-opening them to suit sprint management is not following a principle I try to stick with, that of 'common sense'.

Finally, the agile manifesto really says nothing about NFRs having to be represented as stories. That particular idea is really a vestige of specific agile methods. The true spirit of agile is as much about common sense and 'fit for purpose' as anything else. So, don't be too afraid to stand up and say no to NFRs as stories.

Of course, if you find that NFRs as stories work for your context, excellent. It's just that in my experience, it's really pushing a square peg into a round hole, when we could just as easily fit a square peg into a square hole!

Learned Processes

Seilevel — Tue, 26 Oct 2010 18:59:00 GMT

I know you are going to call me crazy, but I just have to let everyone know. Machines are controlling us. Don’t say I didn’t warn you. You don’t believe me? Okay, I’ll explain.

People come and go in organizations. Systems tend to stay much longer. Simple enough right? Here is the kicker. When that system was implemented, it was implemented to solve a problem. But it did not have all the capabilities required to solve all the problems the business had. So in order to fix the big problem, lots of little problems sprung up.

They weren’t an issue of course because the business had workarounds, usually manual ones. No biggie right? Well, maybe.

Let us say it is five years later and the original people who worked with the system are gone. The replacements were only trained on how to follow the process and not why the processes should be followed. There is the start; the machine has people doing its bidding.

Then a few years later it is decided that some systems should be replaced. So when all of the requirements analysts come in to do their thing, they document the process as is from the users and SMEs. This then gets propagated to the new systems. And thus, the old system lives on through the new system. The old bugs are now required functionality.

We must stop them! When working with old systems and processes don’t just ask what the current state of affairs is. Be sure to ask why it is done the way it is. This was happening on one of my previous projects. The inabilities of the old system were being written into requirements for the new system. Unnecessary needs for manual selections and processes were being maintained.

The project was so large and unruly that other requirements analysts would simply write down the current process and confirm it is how things work. This practice caused very complicated user interactions during the sales process and contract creation. After the fact, people realized that they should have automated more and asked the user questions about what to do less.

Because the software being implemented did not come with all this added functionality, it ended up costing the company much more money to reevaluate what was really needed, what could be covered by alternative existing features, and what would just go unimplemented.

By JHEEP

Want other software requirements posts? http://requirements.seilevel.com/blog/

Enter the Business Engineer

Mendix.com — Tue, 05 Oct 2010 13:53:00 GMT

At Mendix, we find that our customers appoint a particular kind of person to work with our products. Sometimes they’re from IT, sometimes they’re a business analyst or project manager – in any case, they practice the skills of both fields. Times are changing, departmental lines are blurring, and a new breed of business superhero has risen: the BE.

The ‘Business Engineer’ – who are they, what do they do, and why you want to know them.

Who

Until now, these men and women of myth have appeared under the guise of your organizational boundaries – half business and half IT. As champions of business modeling, they dance between the ranks of geeks and suits in companies everywhere, aptly increasing business agility at every collaborative junction. With a flash drive dangling from their sports car keychain and first place positions in both Online Poker and Fantasy Baseball, they are what we believe to be the future of the modern business analyst. In this series of blog posts, we attempt to uncover the true nature of this evolved employee…

What

The title of ‘business engineer’ is not completely novel, as it has been used in the past to describe a role similar to that of a business development manager. Under a new light of enterprise software modeling, this term refers to the business analyst on technical steroids – or the IT whiz with a knack for client relations. These skills, once segregated at a basic level of undergraduate education, have merged into a hybrid force of human capital with more creative power than either part could ever fathom.

These collaborative powers can push companies into unchartered profits, as they attribute to the resiliency of a company’s technology. Agility, as readers of this blog know, affords an organization the ability to change with its business environment. The more easily technological change can occur, the faster and more decisive an organization becomes. Charles Darwin says it best: “In the long history of humankind (and animal kind, too) those who learned to collaborate and improvise most effectively have prevailed.”

The business engineer is not a mythical entity – they may even be sitting in the room as you read this post. Finding them and harnessing their abilities should be a primary goal of any manager. In terms of organizational behavior, they are the ‘central connector.’ In terms of organizational culture, they are the ‘go-to guy.’ And in terms of business agility, they are the binding force between business users and technical experts that have never been able to see eye to eye.

Why

The reasons why you’d want business engineers in your company are significant. They make the technology that your company uses easier to use, more intuitive, and they do so faster and with minimal adversity. With the adoption of visual business modeling, and agile development methodologies, these unsung heroes of the enterprise era are here to stay. Do you know the business engineer at your organization? If not, it just might be you.

Requirements Engineering Conference Is Just Around The Corner

Seilevel — Tue, 07 Sep 2010 00:06:00 GMT

Its being held in Sydney Australia September 27th- October 1st 2010.If you are attending this conference don’t miss out on the Requirements Engineering Education and Training Workshop that is taking place September 28th.

Do you want to broaden your skills? Learn new techniques? This is the workshop for you.

This workshop will address issues related to Requirements Engineering education, both as part of a formal university degree and as ongoing skills training within the workplace. The workshop is intended to go much deeper than a surface discussion of curriculum issues and will examine specific ideas and techniques for teaching and assessing skills needed by an effective requirements engineer.

Curriculum design

Curriculum for undergraduate and graduate level RE studies
Mapping RE elements from the SWEBOK (Software Engineering Body Of Knowledge) to RE curricula
Identifying and incorporating specific RE related topics into the general curriculum and/or software engineering courses
Curriculum for industrial training programs

Techniques for teaching specific RE related skills

Creative methods for teaching stakeholder identification, requirements elicitation, negotiation and consensus building, requirements writing, and other critical RE skills
Specific tools, exercises, and assignments developed to support RE skills training

Assessment methods and practices of RE knowledge and skills

Which assessment method to use: exam, test, case study, essay, report, presentation, or something else?
Strategies for assessment of learning soft skills
What should students be able to do as a result of learning RE?
Methods of objectively measuring assessments

Effective pedagogical methods for teaching RE skills

Survey results related to topics such as the effectiveness of teaching methods, RE skills needed to be effective in industry, skill mismatches between graduating students and industry needs etc.
Studies into the effectiveness of requirements engineering educational practices
Experience reports including industrial training and university level curriculum

Do you want more information?

http://www.re10.org

http://users.cscs.wmin.ac.uk/REET10/Overview.html

“So, what do you do for a living?”: A BA/Product Manager’s guide to surviving cocktail parties

Seilevel — Thu, 10 Jun 2010 13:52:00 GMT

By Jhulgan

I used to dread hearing the question, “So what do you do for a living?” This was often usually asked by a family member or other acquaintances not familiar with the software development lifecycle, IT, or business processes in general. For business analysts, product managers, and other software requirements types, it’s difficult to give an answer without being convoluted or sounding like Tom Smykowski:

This great post expresses a similar insight beautifully, but many of us struggle with good, one-sentence responses to what it is we do everyday in simple English. I thought I would plagiarize some ideas that I’ve heard from colleagues over the years and compile them here:

“We help businesses figure out what software they need to build to solve business problems.” This is a personal favorite of mine that I stole from Marc (who posts under mtalbot on this here blog). It’s especially relevant to IT consultants/contractors. Just about everyone knows what software is, and a lot of people understand that just about every business runs on some sort of software to solve business problems.
“We help communicate the business needs of a system in a language software developers understand.” A variation of this is, “We translate from business to geek”, although I am less fond of the second version because it veers into Smykowski land.
“We make sure the right software is being developed at the right time, for the right people.” The emphasis here is on the right software. This response is nice because it allows you to segue adeptly into a discussion about business objectives.
“We help the business get the most value out of their development dollar.” This response stresses the fact that you are not just a scribe or secretary writing things down, formatting them, and delivering them to the development staff. You are helping make the tough decisions on which features to cut and which bugs to fix, and quantifying those decisions in terms of dollars and cents.
“We work with the business to find the appropriate scope of a software development project and ensure that what is built is what the business expects.” Whenever I am asked the dreaded WDYDFAL question, this is what almost immediately comes to mind. Sometimes I fill in the details of working with pictures to help model current business processes (and desired business processes).

So how about all of our readers? What answers have you come up with? Do you dodge this question altogether, or do you sound like a fumbling Smykowski? Hopefully we can all help each other find good answers to this question. After all, you never know when you’ll be in a meeting with “The Bobs” and the pressure will be on!

You can check out our other blog posts here

Eliminating Software Documentation

Leslie — Mon, 22 Mar 2010 10:25:00 GMT

Not a suggestion for eliminating the process of documenting a software application, but rather a proposed for replacement of the documenting activity and manually produced documents with something more manageable and less likely to frighten the development team.

Initiative for this work comes from a number of discussions I have been following and also an expansion of ideas I have recently documented about best practices for software development.

1.1 Introduction

Developers nightmare – you have spent endless sleepless nights thinking about finally getting your software ready for deployment. It compiles and runs without error. It has been tested and passed user acceptance testing. It is finally ready to be released .. but, you are told that it may not be deployed until the documentation has been approved.

You have been neglecting those 200 page templates that have lying in your inbox while getting your software to compile. Now you have to spend another umpteen nights in the office writing about what it is that you have produced – yawn!

This is not a task that is going to enthuse you to do a quality job. You will probably do your best to get the documents approved asap .. anything to get your code deployed so that you can spend some quality time with family and friends.

Is this a situation you have found yourself in? I have. When I was younger, I quickly learned that this is the downside to the job of being a software developer.

Supposing though, that all you needed to do to get your software deployed, after it was already ‘working’, is to check that everything is up-to-date and consistent, post your deliverables to a ‘release’ area and organize a review meeting, with follow-up!

The following is not meant to be a complete solution, but some ideas for eliminating that boring ‘produce documentation’ task, that always seems to follow any software development effort, not only for programmers, but any member of a development team effort, including analysts, architects, testers, UI designers and any other role that produces work that needs approval.

1.2 What

Instead of identifying a document for delivery as part of a software effort, I propose to break the document into 2 components:

· the document template, and

· document contents.

Where a document has previously been identified as a deliverable, identify the document template as a deliverable. In many cases this allows for several previously deliverable documents to be replaced with a single deliverable – the template that is subsequently populated with the document contents.

This leads to 3 major activities:

· creation and management of document templates,

· production of the contents populating the template(s),

· compilation of the document from its template and contents.

1.3 How

1. Identify the stakeholders that require information that is not part of the compilable software.

2. For each stakeholder, list the information that they require in order to approve the product.

3. Work with each stakeholder to create (or select from a library) the format for a template that is an acceptable method of presenting the required information.

4. Identify dates for the delivery(s) of each template and its needed contents, and track the progress of each.

1.4 Process

For each task under How consider something along the lines of the following activities.

1.4.1 Identify Stakeholders

Stakeholders are anyone within or outside of the development team with an interest in the progress of the product. Anyone not requiring information from the product development effort, is probably not a stakeholder. Typical examples are:

· End users – who would like to see early examples of the user interface and a description of how it operates.

· Project managers – who want to be able to track the progress and effort of everything in the product repository.

· Testers – who will need to be able to access the product requirements in order to maintain test cases.

· Business owners – who will want to k now the scope of the product releases and which requirements are going to be satisfied at each release.

1.4.2 List Information

In the past when each stakeholder has been asked for their needs, they would typically turn to an existing document for reference. This document is often stripped of its current contents and has its contents replaced with information for the new product, without consideration for whether the information is ‘really’ required.

Instead, try starting with traditional document templates and work with the stakeholder to:

1. identify which sections they ‘really’ need,

2. describe the reason for this need,

3. write a description of what is documented in order to satisfy this need,

4. identify a product development timeframe for this information to be available.

Each item of information is given a location in the product repository, and duplicate information is consolidated.

Create a public interface location that always contains the latest version of each piece of information. This is the ‘release’ area.

1.4.3 Accessing Information and Publishing Documents

In many cases a stakeholder may not even require that information is presented in a traditional document form. If the stakeholder is comfortable with the repository used to contain the information, all they may need is easy access to that information.

Using a document sharing tool, such as SharePoint or a Wiki, it is relatively easy to create customized user pages that accesses only the information the stakeholder needs in a layout that makes it easy to access that information.

Alternatively, a scripted documentation tool, such as SoDA, may be used to parse a template and automatically populate it with information from the repository. Give the ability to produce the document to the stakeholder, and the development team need not be concerned with producing documents. They simply inform the stakeholders that a new version is ready for review, publish the information to the release location that the script accesses, and the stakeholder can run the script to extract the required information whenever it is convenient for them.

1.4.4 Delivery Dates And Tracking Progress

Attributes may be added to each repository element for delivery dates, assigned responsibility, progress, stakeholder(s) and a description of its contents. A reusable placeholder is created for each delivery type containing default information for each attribute.

1.5 Conclusion

As stated, the idea is not necessarily to remove documentation from the project, but to reduce the usage of the word on a development effort, and put emphasis on the ‘required’ contents and less on the document itself.

Advantages of this type of approach might be:

· The removal of unwanted/unused documentation.

· Tracking by more manageable chunks.

· Elimination of duplicate information.

· Removal of confusion over what is ‘most current’, since there is a single delivery area for every unique deliverable.

· An end to the developers nightmare of having to produce reams of documentation, after the ‘fun’ part is over.

I recognize that not all deliverable documents can necessarily be replaced in this manner. But maybe it is a start towards removing the dreaded word ‘documentation’ from a project’s deliverables list and maybe a compromise between agile proponents of minimizing documentation and those requiring documentation according to some sort of standard.

1.6 References

Links to articles that inspired this work.

http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=14867479&gid=1976291&trk=EML_anet_qa_ttle-0Qt79xs2RVr6JBpnsJt7dBpSBA

Best Practices

Create a product information repository that contains everything that is going to be shared amongst product stakeholders. Using this repository:

Best Practices - Ad Hoc Procedures

Leslie — Thu, 18 Mar 2010 06:16:00 GMT

Ad Hoc Procedures

My belief is that software development should be more of a science and contain as little artistry as necessary. It is great to come up with ingenious processes and guidelines for developing your software, but if they impact your colleagues you must get buy-in from everyone who is impacted before you start using them.

Some people achieve satisfaction by getting a compliment for a ‘job well done’, some for a ‘working really hard’ others for ‘being a team player’. Nothing gives me more pleasure than having a colleague answer ‘Yes’ to the question, “Did I make your life easier?”.

Recommended procedures for working with documents should be documented, available and approved by all users of those procedures. Examples of these procedures include:

Location of document templates and how to access them.
The purpose of the document template and where to enter information into the template.
Documentation numbering and versioning conventions.
How to check out from and check in to a document repository system.
How to use the product or project glossary.
The purpose of the styles and properties that are used by a document.
The process for baselining, or creating a new version of a document.

Document your procedures and make sure that everyone that needs them understands them and has easy access to their documents.

Further articles will expand upon the obove bullets, with examples.

[1] This was not always the case .. when I first started programming I invented some extremely ingenious and complex software procedures, that I was proud of at the time. I look back at those days and cringe.

Editor's Note: Check out the list of all related best practices.

Best Practices - Document Content

Leslie — Mon, 15 Mar 2010 04:47:00 GMT

Unnecessary Documentation

The first section that I look for in a document, is the paragraph that describes ‘who this document is written for’ and ‘what benefit they can expect to gain by reading this document’. If I do not see my role, or I do not see any benefit from me spending time reading the document, then I have to ask myself the question, ‘Do I want to read this document?’ I want this information to be displayed to me asap, such that I waste as little time as possible, reading a document that is of no interest to me.[1]

When I review a document or document template, another task that I might perform, is to consider each section in the document and ask the question, “Who asked for this information to be entered into this document?’ Or, another way of putting the question is; Who is going to read this and get value from it?[2]

Typical subsequent sections of a document I have seen that need this question applied include:

Document History – How many readers want to know what changed between versions from 1.1 through to 1.15?
Definitions and acronyms – leave them in the glossary, nobody needs to read these in the document. If anything I want to be able to reference these while reading the document without having to leave the current page. (See also ‘Duplication’.)
References – Put the reference in the section that uses it. I do not need to see a separate page containing a complete list of document references. I am not going pull up all the referenced documents and have them prepared in case I come across documentation that makes reference to one of them.

Before you document something, find out who it is that needs this information documented.

Which leads me to ..

Document Content Organization

On a related issue: There are tools for recording document versions. Any decent tool that is intended as a central repository for files of any type will record the version of the document and allow the author to add comments to the version. Such tools include SharePoint, LiveLink and ClearCase amongst many others. So why is it that when I open most documents, one of the first things to be presented for my reading pleasure is a table containing a version history. Honestly, I have seen version histories that span many pages and are quite detailed. They explain every change that has been made to the document over the last Millennium. Who wants to read this stuff, and why is it the first information that is presented to the reader after getting past the front page? If we are using a document management system on this project, (and I certainly hope that we are) all of the version history information should be documented inside the tool. Why is it being repeated in the document?

Many years ago, before the advent of intelligent document comparison tools, this information may have been useful in the front of the document. It allowed to reader to determine which parts of the document have changed since the last time they read it. Today, any Word processor worth purchasing will inform you what has changed since the last time you reviewed the document.

I realize that there are some roles on the project to whom this information is important, QA or auditors, for example. If you must publish this information with the document, put it in an appendix to the document, or better still, extract it from your document management tool into its own document. Then distribute the version history document only to those people that want it.

Now that the version history is out of the way, what do we now see when we open the front cover of the document? The table of contents. It is useful to be able to easily locate this, but I question whether it is the first piece of information that I want to read. What I need to know, as soon as possible is, ‘Should I be reading this document?’ What is going to answer this question – the Introductory material in section 1.

The first question I want answered is; Is this document describing a system that I am interested in?
The second question is; Is the information in this document pertinent to my relationship with the application?
The third question is; What information am I going to get from this document?
Fourthly: What is my responsibility towards the information in this document?

Hopefully, the answers to these questions become apparent as soon as I open the front cover of the document.

Put the appropriate information in the appropriate place and avoid showing unnecessary information to the wrong people.

[1] Typically, I expect to see this section, right after the document overview, which tells me that I am not a part of this project anyway.

[2] If the content is relevant, then I might ask if this information is implied within the section that describes the ‘Audience’ for the document.

Editor's Note: Check out the list of all related best practices.

Best Practices - Inconsistent Documentation

Leslie — Sat, 13 Mar 2010 05:40:00 GMT

If you are writing a letter to your mother, it is fine to create a new a new blank document, type your random thoughts, add highlighting, colors and emphasized text where you want to make and get a point across, and basically format the document with any creative ideas that you feel appropriate.

When working with documents in the workplace, ad hoc formatting is probably not appropriate. Yet I see so many requirements and other technical documents that were written by people who thought that they were writing a letter to their parents.

Imagine if every programmer on the development team wrote source code using their own personal coding standards. Nobody would be able to maintain someone else’s code. It should be the same with documentation. Every document should be written from a predefined document template that includes documentation standards (instructions for use), a consistent set of styles and properties.

The problem not only applies to textual documents, but also to diagrams. UML for example, defines a set of artifacts in terms of a set semantics and rules that apply to that artifact. (As far as I am aware) the icons used to represent an artifact are not defined within UML standards. Not only that, but UML allows the stereotyping of defined artifacts, which in turn leads to a customized representation of the artifact.

An example, I might be, using an arrowhead to indicate the initiator of a use case (which I do), and someone else using a dashed line to indicate the same thing. Now there needs to be an explanation in each document of the meaning of which notation that is being used. Not only that, but if both diagrams contribute to the same document, you are going to confuse your readers.

Use a set of rules for identifying a particular meaning on a diagram. If there is no rule for it, then make one up and explain what the particular notation means (although the more project rules there are , the less explanation needs to be added to the diagram or document). Say for example, you wish to highlight parts of a diagram to indicate that they are candidates for change, but there are no project specific rules for indicating how to highlight changing components. Then go ahead and shade the items (or whatever highlight you prefer) and explain what the highlighting means.

Which leads me to; the number of times I see a figure in a document without, not just a description of the figure, but not even a reference to it. Why did you put this figure here, if you are making no reference to it?

If there are 2 ways of doing something, pick one that works, describe it and stick with it for the length of the project.

Editor's Note: Check out the list of all related best practices.

Best Practices - Ambiguity

Leslie — Sat, 13 Feb 2010 05:34:00 GMT

How many times have you experienced a disagreement between colleagues, only find out later in the project that they were both correct. Chances are that they were using the same word, but both had different ideas of its meaning. [1]

I can derive hours of entertainment by playing word games with my friends, by picking a word they are using and purposely give it a definition that they are not thinking of. The important thing is that no one definition is incorrect, but it may be different.

For example, ‘Closing the door’; everyone knows when a door is closed and when it is not – don’t they? I might argue that no 2 people have exactly the same definition of a closed door. I might argue that a door that is ajar by an inch or so is actually closed. This is not strictly incorrect unless all parties involved in the conversation have agreed to a definition of a ‘closed’ door.

Obviously, this is not the sort of discussion that you want to have in the work place, but it is going to happen if not everyone has the same definition for an ambiguous term. Ok, you may say, but everyone in the work place has a pretty good idea (or at least a close idea) of what constitutes a closed door, such that we do not have to define it. Well if you are working for a word processing software company – yes; but if you are writing software for an application that controls submarines, and you want me to ride on that sub, I hope that the word ‘closed’ when referring to doors, was well-defined early in the development process.

My recommendation is to maintain a glossary of commonly used terms on your project that could cause confusion if open to several interpretations. We know that ideally requirements should not contain adjectives or adverbs, such as near, far, slowly or quiet. Sometimes we need to use these words on a project, in which case they should be defined in a glossary. For example; if we often use the word slowly, then define it as; Slowly – implies that the vehicle is traveling at less than 10% of its maximum speed.

I find that a RequisitePro project works well for maintaining a glossary of terms. MS Excel and other spreadsheet applications may work equally well; so long as you can order terms, give them several attributes (acronym for example) and link them (as synonyms of each other, for example).

Next time you are in a disagreement with anyone (be it at work or at your local), listen to the words that they are using and try to figure out which ones are having a different definition applied to that which you are using. You’ll come to an agreement eventually (that is of course unless their objective in arguing is to maintain the argument).

Whenever possible, do not use a word (acronym or term) that is ambiguous, because you can be sure more than one interpretation will be used.

[1] I’m sure that we have all experienced this game as children. Leslie, I thought that I told you to tidy your room .. it is tidy .. no, it isn’t.

Editor's Note: Check out the list of all related best practices.

Best Practices - Duplication

Leslie — Sat, 13 Feb 2010 04:22:00 GMT

How often do you see the same piece of information documented in 2 places? I am used to seeing requirements information copied into design documents; whole sets of requirements being copied into a test repository and diagrams copied from one document to another. Unless you employ a strict change management control system that includes a traceability scheme, this sort of practice is going to prove expensive, for 2 main reasons:

The work of maintaining information is being done twice.

More expensively, if one artifact changes and the other doesn’t, how do we know which is correct? [1]

Employing an automatic update scheme, a traceability scheme which shows when something has changed or a strict configuration management scheme which prevents artifacts from being changed, will go some way to solving the duplication problems, but again they are expensive.

Rather than spending time and money in trying to control duplication; I recommend, ‘Don’t Do It’. Here are some schemes that can be used to prevent duplication:

Put the information in a central repository and reference it with hyperlinks.

If you must have the information displayed in two separate places, use Object Links and Embedding (OLE). Extract the information from both artifacts, place it in its own document and embed the document as an OLE.

Use document generation tools, such as SoDA, to insert duplicated information into your documents.

Ask yourself the question; ‘Do I need to put this information here?’ Or, ‘Can I reference the same information, located somewhere else?’

Do not copy, either use a link or make a reference if you absolutely must have it here.

[1] The worst example of this was on a contract where the test team did not like the way the developer’s document repository was organized, so they copied the developer’s documents into their own repository. The wrong tests were consistently being executed against the code.

Editor's Note: Check out the list of all related best practices.

Best Practices

Leslie — Fri, 12 Feb 2010 08:10:00 GMT

This following blogs contain rants and recommendations for good practices, useful not only for when delivering software, but that can also be used any time organization is required.

The most common improvements that can be leveraged on any (some on every) development process it has been my experience to be involved with, are the following:

Duplication - Copying and pasting, work (text or diagrams) from one place (or document) to another.

Ambiguity - Using the same term(s) with more than 1 meaning on the same project.

Inconsistent Documentation - Documents that supposedly describe the same information (or have similar purposes), but have different content. Deviating from the approved document template.

Unnecessary Documentation - The creation of documentation, without first identifying an audience.

Document Content Organization - Related to unnecessary documentation. This rant is concerned with putting the right information in the right place in the document.

Ad Hoc Procedures - Concerns having a standard set procedures for handling files and making sure that everyone on the project understands how to use them.

I will discuss each point in detail in my following posts ..

Thoughts on Specifying Requirements

Leslie — Fri, 12 Feb 2010 08:04:00 GMT

Requirements

I have been working with requirements for more than 20 years. To be honest, it was several years before I understood the true purpose of requirements. The enlightenment came about when I was tasked with documenting a presentation to my colleagues that described the characteristics of a ‘good’ requirement. The characteristics that the team came up with included:

Complete – A functional requirement should describe all observable inputs, all observable outputs, when it can occur, who (actor that) is allowed to initiate the requirement and the maximum time that the requirement is allowed to complete.
Consistent – The requirement should not be in conflict with any other requirements for the project. For example, if one requirement states that all user inputs will be processed within 5 seconds of entry and another requirements states that system shall respond to a particular user input within 10 seconds, there is a conflict in the requirements.
Correct – Are the requirements specifying a solution that the business wants implemented?
Design independent – If there is another way of specifying the requirement which will result in a different solution to the problem, then it probably contains design information and should be abstracted out to allow for all possible design decisions. For example, stating that when the main window is closed that the system will logout the user etc, is too detailed. Supposing we decide not to build a windowed application? A better way to abstract the requirement would be to say that when the user exits the application that they will be logged out, etc.
Feasible – Is it possible to implement the requirement within the specified time and budget? (And, we might want to ask if there is there a positive return on investment (ROI) for implementing this requirement?)
No negative requirements – Stating the system ‘shall not’ do something is either untestable or irrelevant. The requirements state what the system will do; anything else is out of scope. For example, instead of stating that something shall not be ‘red’, state the colors that it may take. Irrelevant example; stating that the system ‘shall not’ allow a user to view user information, is already covered by a requirement that an administrator shall be able to view user information. The fact that it has been stated that administrators may view this information, excludes all other actors, unless explicitly stated. A rule of thumb is that the system does nothing unless it is stated as a function of the requirements.
Relevant – Is the requirement in scope for the current effort.
Testable – Is it possible to define specific ranges of inputs and outputs for the requirement such that when the implementation of the requirement is executed all inputs cause the system to produce the specified outputs, otherwise the implementation of the requirement fails?
Unambiguous – The requirement should not contain any words that are open to interpretation. This includes all adjectives and adverbs, unless they are clearly defined in a project glossary. For example, the system shall allow ‘many’ users to change their profile. Unless the word ‘many’ is explicitly defined this requirement has little meaning; and it can be satisfied by allowing exactly 2 users to change their profile and no more.

Functional Requirements

In addition to the above, functional requirements include the following characteristics:

Precondition (optional) – when can the functional requirement execute? The precondition specifies what state the system must be in before the requirement may be initiated. Not all functional requirements are able to execute at any time. If using a use case approach to writing functional requirements, the use case precondition states what use case(s) must have completed prior to this use case being able to initiate, and each step in the use case has an implied precondition, which is the previous step in the use case. (Sometimes the precondition may be implied by the wording of the requirement, in which case it does not have to be explicitely stated.)
Time to complete – if a functional requirement does not have an associated maximum time to complete, then if the implementation of the requirement does nothing it will never fail testing. If it never fails testing and never does anything it will never get deployed into production. Again, using a use case approach, the whole use case may be given a time to complete, or you may specify time to complete for individual steps. If a group of steps are assigned a time to complete, and that time expires during testing, then every step in that grouping is considered to have failed the test.

Non-Functional Requirements

Non-functional requirements additionally include the following characteristics:

Reference to a functional requirement – non-functional requirements place constraints upon functional requirements. Functional requirements may include the meaning of the non-functional requirement in their specification. The reason non-functional requirements are specified separately is because they often impact many functional requirements. We do not want to duplicate the requirement. Therefore it is called out as a separate requirement and references the functional requirements that it impacts.

Definition of a Functional Requirement

From Wikipedia: ‘In software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs (see also software).’

When not employing use cases, I use a template for specifying requirements of the following format: 'When' in a certain state* 'and' 'upon’ some externally visible event occurring (the trigger), ‘the system shall’ do something externally visible, ‘within’ a certain time frame.

['When' in a certain state is optional, and if omitted means that the requirement is valid in under all circumstances, i.e. it has no precondition.]

For example, 'When' the ATM is free, 'and upon’ a customer inserting a valid debit card into the ATM slot, ‘the system shall’ request that the customer input their PIN through the ATM user interface, ‘within’ 5 seconds.

(The 5 seconds of course applies to the system and not to the customer entering their PIN.)

Here are some examples of requirements that do not satisfy the template. See if you can figure why before reading my answers.

When requesting a customer PIN, and upon a customer entering their PIN through the ATM UI, the system shall verify that the PIN is correct for the card, within 5 seconds.
Upon verification of the customers PIN, the system shall inform their customer that they may select an action from the ATM UI, within 5 seconds.
Upon dispensing cash to a customer, the system shall send a message to the Banking System requesting that the customer’s account balance be deducted by the amount dispensed.
When a customer card is inserted, and upon the Banking system receiving a deduction message, the system shall give the customer their card back, within 5 seconds.
Upon a customer entering the 'Display Balance' command, the system shall request the customer balance from the Banking system, within 5 seconds.

In my opinion these requirements contain the following errors:

‘Verify the PIN’ is not an externally visible action. If the PIN is valid, the selection screen will be displayed. If the PIN is invalid, an error message will be displayed. The first case was already covered by the original requirement when it included the word ‘valid’. We need to add another (separate) requirement to cover the invalid situation.
The trigger is not externally visible. We cannot observe the system verifying the customer PIN. In fact the act of ‘verifying’ the PIN is a design decision. Our designers might equally decide that the PIN is verified by the Banking System. In fact, in reality, it probably is.
No time frame specified. The banking system is going to lose a lot of money if the ATM sends out deduction requests once a year.
The trigger is not an event that the ATM system can recognize. The Banking System has to somehow inform the ATM system that it received the message. It is upon reception of this event that the requirement initiates.
No precondition. The customer must first have entered a valid PIN, otherwise the system cannot be sure whose balance to request.

In my next post I intend to identify some best practices for working with requirements..

Help your stakeholders review your requirements

Craig Brown — Fri, 13 Feb 2009 10:58:00 GMT

Invest in User Stories

Craig Brown — Fri, 09 Jan 2009 12:01:00 GMT

User stories have a place in modern requirements management. They may not be going to replace use cases but you shoulod know how to write them well.

Invest In Good User Stories

View SlideShare presentation or Upload your own. (tags: agile scrum)